Category Archives: Certificates

SSL: How to Export Non-Exportable Private Keys

When migrating from one computer system to another, it may be necessary to transfer or import/export certificates from one system to another but there can be issues when exporting the private key from the source system.  When installing a certificate, the private key is not marked as exportable by default as shown below and if one is not paying attention could click right by it, not realizing their potential mistake until years later when needing to export the certificate to a new machine:

If Mark this key as exportable is not checked, you can still export the certificate on the source system and import it onto the destination system without any problems…at least on the surface.  You won’t know there’s an issue until you try to access a secure site which requires the private key to complete an authentication request at which point you wonder how in the world you’re going to get the private key.

If the source machine is a 32-bit machine, you can use a utility called Jailbreak to export “non-exportable” private keys/certificates.

1. Once downloaded, extract the contents of Jailbreaks ZIP file and execute Jailbreak.exe.  In the screenshot, I have right-clicked and have “Run as” selected because Administrative rights are required to run it.  However, in this case, the certificate I needed to export was a User specific, not a machine specific certificate so I needed to run Jailbreak as the user, thus the user was added into the local Administrators group and “Run as” was not required.

2. Jailbreak will launch a Jailbreak MMC Certificates console as shown below.  Locate the certificate in question and then  In this case, the certificate was in the Current User | Personal certificate store.  Right-click the certificate and choose Export.

3. On the Export Private Key screen, select Yes, export the private key and click Next to continue.  Complete the export wizard and then import the newly exported certificate onto the destination system.  With the private key, any applications/sites requiring the private key should work just fine.

Leave a comment

Filed under Certificates, Utilities

Error 0x80092013 When Starting an Enterprise Subordinate CA

Working on a Windows 2008 two-tier Certificate Infrastructure implementation, the installation of the Root CA went without a hitch, but when trying to start the certificate server service on the Enterprise Subordinate CAs, I received the error (in summary): “0x80092013 certificate revocation server is offline”.

Whether its right or wrong, what I had attempted first when building the Root CA, is to specify a UNC path the the Root’s CRL in the Extensions tab of its properties. I had past success using UNC paths when working with Windows 2003 certificate servers and figured that Windows 2008 would work more or less the same, and I guess it does, but in this particular case it was less.

Opening PKIView on the Enterprise Subordinate CA after the service failure, I saw a screen similar to the one below, taken from this blog post: http://www.cupfighter.net/index.php/tag/0x80092013/

I won’t bore you with all the details, but to resolve the issue, I used an HTTP path for the Root CRL extension pointing to an IIS virtual directory on the Enterprise Subordinate CAs. Once the CRL was copied to the Subordinate CAs, the certificate services started without a problem.

Another option would have been to disable/ignore the CRL check as found below:
http://khurramullah.wordpress.com/2008/08/07/certificate-services-unable-to-start/

I have not figured out why the file/UNC path to the CRL did not work. Perhaps there will be time to explore it further.

2 Comments

Filed under Certificates, Windows Server

How to Force a DC to Attempt Certificate Autoenrollment

After installing a new Microsoft Certificate Server, the Event Logs on the Server 2003 domain controllers displayed an Autoenrollment error, Event ID 13 (Access is Denied) while on the 2008 domain controllers, an Event ID 13 error with the Source CertificateServicesClient-Request….or something close.

The fix for the Autoenrollment problem was the following found on an MS Support Forum:

The event 13 from Autoenrollment message may be related to the new DCOM security enhancement of Windows Server 2003 SP1. Windows Server 2003 Certificate Services provides enrollment and administration services by using the DCOM protocol. Certificate Services provides several DCOM interfaces to make these services available. For correct access and usage of these services, Certificate Services assumes that its DCOM interfaces are set to allow remote activation and access permissions.

However, Windows Server 2003 SP1 introduces enhanced default security settings for the DCOM protocol. Specifically, SP1 introduces more precise rights that give an administrator independent control over local and remote permissions for launching, activating, and accessing COM servers. Therefore, because of the enhanced default security settings for DCOM that are introduced by SP1, you may have to update these security settings to make sure of the continued availability of these services after you install SP1.

Suggestions:

1. Please check to ensure that a new security group, CERTSVC_DCOM_ACCESS, has been created after applied the SP1.
2. Please add the “Domain Users”, “Domain Computers”, “Domain Controllers” groups to the new CERTSVC_DCOM_ACCESS security group.
3. Then, we can have Certificate Services update the DCOM security settings by running the following commands:

certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc.

Thinking I had my problem fixed, I wanted the DCs to attempt an autoenrollment once again, however, in my impatience, I didn’t want to wait for this to happen.

Performing the steps listed below (they worked for 2003 and 2008) forced a certificate autoenrollment on the DCs:

1.    Backup/Export the registry key:             
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache

2.    Delete the AEDirectoryCache registry key

3.    From the Command line, execute GPUPDATE /FORCE

Shortly thereafter, I reviewed the Event Logs on the DCs and they stated certificate autoenrollment was successful at which point I opened the Certificate Authority MMC on the CA and saw that certificates had indeed been issued.

2 Comments

Filed under Certificates, Windows Server