Hi! I'm trying to enroll computer certificate via mmc/certificates console for computer. I fail with error "Request not supported" every time. In application log there is error "Certificate enrollment for Local system failed to enroll for a Machine certificate with request ID N/A from SuppS.Kaheksa.XI\Kaheksa XI (The request is not supported. 0x80070032 (WIN32: 50))." The CA is enterprise subordinate. I can requet certificate for user. Thanks, Urmas UV

Please provide the following: Client and Server OS versions Debug output from enrollment attempt To gather the debug logs on the client, Run the following command from an elevated cmd: "certutil -setreg enroll\debug 0xffffffe3" Attempt to enroll for the machine certificate again Find the relevant output in %windir%\certenroll.log To disable enrollment logging, run the following command from an elevated cmd: "certutil -delreg enroll\debug"

CA server is 2008 R2 Enterprice. Client is CA server itself, asking default computer certificate. The output is: ========================================================================402.511.948: Begin: 14.04.2010 22:52 24.185s402.516.0: MMC.EXE402.520.0: GMT + 3,002005.208.0: certcli.dll: 6.1:7600.16385 retail2005.208.0: certenroll.dll: 6.1:7600.16418 retail3000.835.0:<2010/4/14, 22:52:25>: 0x80094004 (-2146877436)2032.4215.0:<2010/4/14, 22:52:25>: 0x80094004 (-2146877436): Fetch Id3000.835.0:<2010/4/14, 22:52:25>: 0x80094004 (-2146877436)3000.858.0:<2010/4/14, 22:52:25>: 0x80094004 (-2146877436)3000.835.0:<2010/4/14, 22:52:26>: 0x80094004 (-2146877436)2032.1524.0:<2010/4/14, 22:52:26>: 0x80094004 (-2146877436)2007.195.0:<2010/4/14, 22:52:27>: 0x80091002 (-2146889726): 3DES_1122007.195.0:<2010/4/14, 22:52:27>: 0x80091002 (-2146889726): DESX2007.195.0:<2010/4/14, 22:52:27>: 0x80091002 (-2146889726): AES-GMAC2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): Administrator2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): ClientAuth2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): EFS2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): CAExchange2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): CEPEncryption2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): CodeSigning2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): CrossCA2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): DirectoryEmailReplication2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): DomainController2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): DomainControllerAuthentication2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): EFSRecovery2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): EnrollmentAgent2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): MachineEnrollmentAgent2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): EnrollmentAgentOffline2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): ExchangeUserSignature2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): ExchangeUser2027.6875.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392)2032.3029.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392): IPSECIntermediateOnline2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): IPSECIntermediateOffline2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): KerberosAuthentication2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): KeyRecoveryAgent2027.6875.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392)2032.3029.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392): OCSPResponseSigning2027.6875.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392)2032.3029.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392): OctoXComputer2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): OctoXILO2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): OctoxKRA2027.6875.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392)2032.3029.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392): OctoXOCSP2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): OctoXOCSPResponseSigning2027.6875.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392)2032.3029.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392): OctoXServer2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): OctoXUser2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): RASAndIASServer2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): CA2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): OfflineRouter2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): SCMDMGCM (OctoX)2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): SCMDMMobileDevice (OctoX)2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): SCMDMWebServer (OctoX)2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): SmartcardLogon2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): SmartcardUser2032.2825.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): SubCA2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): CTLSigning2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): User2032.2807.0:<2010/4/14, 22:52:27>: 0x80094012 (-2146877422): UserSignature2027.6875.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392)2032.3029.0:<2010/4/14, 22:52:27>: 0x80094800 (-2146875392): Workstation2009.4916.0:<2010/4/14, 22:52:27>: 0x80094004 (-2146877436)2008.1048.0:<2010/4/14, 22:52:27>: 0x80094004 (-2146877436)2014.4239.0:<2010/4/14, 22:52:27>: 0x80094004 (-2146877436)2027.7483.0:<2010/4/14, 22:52:31>: 0x80004003 (-2147467261)2009.4916.0:<2010/4/14, 22:52:31>: 0x80094004 (-2146877436)2009.4621.0:<2010/4/14, 22:52:31>: 0x80094004 (-2146877436)2009.1152.0:<2010/4/14, 22:52:31>: 0x80094004 (-2146877436)417.767.0:<2010/4/14, 22:52:31>: 0x80004003 (-2147467261): NULL GetStdHandle417.767.0:<2010/4/14, 22:52:31>: 0x80004003 (-2147467261): NULL GetStdHandle2009.2640.0:<2010/4/14, 22:52:31>: 0xc (WIN32: 12): Microsoft RSA SChannel Cryptographic Provider2009.2641.0:<2010/4/14, 22:52:31>: 0x28 (WIN32: 40): le-Machine-dd17ee62-aa37-40e9-b2b5-79dc68e286e72014.3720.0:<2010/4/14, 22:52:31>: 0x80094004 (-2146877436)708.1086.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)708.1486.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)708.1626.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)708.882.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)2027.2474.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50): SuppS.Kaheksa.XI\Kaheksa XI3007.1485.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)2027.2137.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)2009.2640.0:<2010/4/14, 22:52:32>: 0xc (WIN32: 12): Microsoft RSA SChannel Cryptographic Provider2009.2641.0:<2010/4/14, 22:52:32>: 0x31 (WIN32: 49): le-Machine-dd17ee62-aa37-40e9-b2b5-79dc68e286e72027.6840.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)2032.3412.0:<2010/4/14, 22:52:32>: 0x80070032 (WIN32: 50)2027.1477.0:<2010/4/14, 22:52:32>: 0x80094004 (-2146877436)2032.3560.0:<2010/4/14, 22:52:32>: 0x80094004 (-2146877436)2032.2503.0:<2010/4/14, 22:52:34>: 0x80070032 (WIN32: 50)2032.1943.0:<2010/4/14, 22:52:34>: 0x80070032 (WIN32: 50)2032.5129.0:<2010/4/14, 22:52:34>: 0x80070032 (WIN32: 50)402.377.949: End: 14.04.2010 22:52 34.665s The same error appears also on Windos 7 workstation or on other Windows 2008 servers. No mark is left into CA database (it is not failed request). Thanks!, Urmas UV

Can you try this on a machine without a space in the name: "SuppS.Kaheksa.XI\Kaheksa XI"?

Kaheksa XI is name of my CA, supps.kaheksa.xi is FQDN of CA.How?Urmas UV

My mistake. Thanks for clarifying.Enable debug logging on the CA with "certutil -setreg ca\debug 0xffffffe3" and provide the output in %windir%\certsrv.logHow is the machine getting enrollment policy: LDAP or CEP (Certificate Enrollment Policy Service)? If CEP, what authentication method is the service using to authenticate clients?How is the machine submitting requests to the CA: LDAP or CES (Certificate Enrollment Web Service)? If CES, what authentication method is the service using to authenticate clients?From the log, you are getting policy (templates) fine, but the submission to the CA is returning ERROR_NOT_SUPPORTED. If using CEP and CES, try clearing the machine's cached credentials with "certutil -f -credstore * delete" and retry enrollment.

Hi,I have only one role service installed - certification authority. So, probably I use LDAP :) UV

I cleared the cache and enabled login. Then I requested computer certificate via mmc on CA. Output from certsrv.log:========================================================================Opened Log: 15.04.2010 20:54 13.812sGMT + 3,00certcli.dll: 6.1:7600.16385 retailcertsrv.exe: 6.1:7600.16385 retail508.1321.0:<2010/4/15, 20:54:13>: 0x2 (WIN32: 2): DBMaxReadSessionCountCertSrv: Opening Database C:\Windows\system32\CertLog\Kaheksa XI.edbCertSrv: Database open420.386.0:<2010/4/15, 20:54:14>: 0x2 (WIN32: 2)419.5484.0:<2010/4/15, 20:54:14>: 0x80090029 (-2146893783): crypto::FS_PROP_KEY_USAGE_COUNT_ENABLED1006.794.0:<2010/4/15, 20:54:16>: 0x80070490 (WIN32: 1168): msPKI-Key-Security-Descriptor1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): OctoXComputer1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): CAExchange1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): DirectoryEmailReplication1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): DomainControllerAuthentication1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): EFSRecovery1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): EFS1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): DomainController1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): WebServer1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): Machine1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): User1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): SubCA1004.5442.0:<2010/4/15, 20:54:16>: 0x80094800 (-2146875392): AdministratorCertSrv: Policy Module Enabled (Windows default)CertSrv: Exit Module[1] Enabled: 27f (Windows default)419.5484.0:<2010/4/15, 20:54:16>: 0x80090029 (-2146893783): crypto::FS_PROP_KEY_USAGE_COUNT_ENABLEDCertSrv: Certification Authority Service Ready (3s) DC=AD2.Kaheksa.XI ...CertSrv: Base + Delta CRL Publishing Enabled, TimeOut=67981s, 18 Hours, 53 Minutes, 1 Seconds457.2502.0:<2010/4/15, 20:57:39>: 0x80070032 (WIN32: 50)504.108.0:<2010/4/15, 20:57:39>: 0x80070032 (WIN32: 50)515.318.0:<2010/4/15, 20:57:39>: 0x80070032 (WIN32: 50)515.220.0:<2010/4/15, 20:57:39>: 0x80070032 (WIN32: 50)Thanks, UV

The request is failing on the server side when trying to verify the client's FQDN Are there any special characters in the name or any other reason why this would fail?To be clear, the server fails while trying to get the name like: "CN=<machine>,CN=Computers,DC=<domain>,DC=<domain>,DC=<domain>,DC=<domain>"

Interesting, where you can see this error?Machine name is supps.kaheksa.xi, I also tried from uv.kaheksa.xi - nothing special. CA name is supps.kaheksa.xiHow does CA try to get the name? How can I test it? - nslookup solves the name as it is. It also solves domain controllers.Thanks!,UV

And distinguished name is "CN=SUPPS,OU=Servers,OU=KAHEKSA XI,DC=Kaheksa,DC=XI"UV

The client is getting far enough to create and submit the request. I know that because the server log shows an attempt to enroll but returns 0x80070032 to the client. A little debugging on my own CA shows where your request is failing, however I have not been able to reproduce your error, so I am not sure why the name lookup is returning ERROR_NOT_SUPPORTED.Are there any other idiosyncrasies in your setup that might be relevant?

No, I don't see anything specific. It is W2K8 R2 domain and there are offline root CA and Issuing/Policy CA.And it worked before. From one moment I just cannot deploy certificates for computers.Can it be some kind of DCOM issue? - After restart I'll get DCOM error 10016.Thanks,UV

Hi, You can refer to the following thread to check the DCOM permission: http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/8bb5807f-73ba-4092-abc8-283d8fced6c4?prof=required Hope it helps.This posting is provided "AS IS" with no warranties, and confers no rights.

I solved the problem some minutes ago - there was customized setting under local GPO CC/WS/SS/LP/SO/Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Disable all It seems that outgoing NTLM traffic from CA must be enabled. Thank you for your help, Urmas UV

Glad that the issue has been resolved. Have a nice day.This posting is provided "AS IS" with no warranties, and confers no rights.