Restoring certificates from the SMTP Exit Module data

If you restore a certification authority from a backup after a disaster has occurred, you will probably find that certificates were issued in the period between the last backup and the system failure with corresponding data loss.

These certificates are now not stored in the restored certificate authority database, so they cannot be restored if needed.

If you are using the SMTP Exit Module, you can at least determine the serial numbers of the certificates from the sent e-mails and revoke them.

Sometimes it is necessary for a certificate issued by a certification authority to be withdrawn from circulation even before its expiration date. To make this possible, a certification authority keeps a revocation list. This is a signed file with a relatively short expiration date, which is used in combination with the certificate to check its validity.

The basis for the successful recovery of a certification authority in the event of a disaster is that a functioning backup is available. How this is created is described in the article "Create a backup of a certification authority" described.

Instead of the SMTP exit module it would also be possible, develop your own exit modulewhich writes the certificates, for example, to the file system (on a remote server or in connection with a DFS replication) or uploads them to an external database.

Procedure

Check if the serial number already exists

First, check if the serial number already exists in the certification authority database.

certutil -view -restrict "SerialNumber={serial number}"

Create dummy certificate

In the event of a disaster, in most cases one is no longer in possession of the certificates. Since the revocation of a certificate requires that a corresponding certificate is in the certification authority database, a dummy certificate with the corresponding serial number must first be generated. As "signature certificate" one selects that of the certification authority.

certutil -sign "{serial number}" {filename}

Import dummy certificate into the Certification Authority database

The created certificate can now be imported into the certification authority database.

certutil -importcert {filename}

Certificate revocation

It can then be blocked via Certificate Authority Management Console or command line.

certutil -revoke {serial number} {reason code}

The possible codes for the blocking reason can be found in the table below:

Code	Designation	Description
0	Unspecified	This is the default setting and indicates that there is no specific reason for the revocation.
1	Key Compromise	The private key of a certificate was stolen or otherwise known to unauthorized third parties.
2	CA Compromise	The private key of the certification authority was stolen or otherwise known to unauthorized third parties.
3	Affiliation Changed	If the content of the certificate (e.g. the name of the user) has changed, a new certificate must be issued.
4	Superseded	The revoked certificate was replaced with a new certificate.
5	Cessation of Operation	The operation of the service belonging to the certificate was discontinued, for example, because there is a new service under a different name.
6	Certificate Hold	The certificate is revoked temporarily. This revocation type is the only one where the revocation can be subsequently undone.
8	Remove from CRL	If a certificate was revoked with reason "Certificate Hold" and delta revocation lists are used, the revoked certificate is kept in the delta revocation list with this code until the entry in the main revocation list is removed.
-1	Unrevoke	If a certificate has been revoked with reason "Certificate Hold", this code can be used to unblock it via command line. Likewise, in the auditEvent 4870 the undoing of a certificate revocation is marked with this code.

Publish new blacklist

For the blocking to be effective, a new revocation list still needs to be published.

certutil -crl

See also article "Create and publish a certificate revocation list„.

Please note that until the previous revocation list expires, there is no guarantee that PKI subscribers will recognize the revocation as such, since (at least in the Windows ecosystem) revocation lists are stored in an client-side cache (buffer) be held available. The same also applies to Responses from the Online Responder (OCSP).

Error when using Windows Server 2008 R2

The following error may occur on Windows Server 2008 R2:

CertUtil: -CRL command FAILED: 0xc0000005 (-1073741819)
CertUtil: The instruction at 0x1x referenced memory at 0x1x. The memory could not be %s.

In this case, it helps, this Hotfix to install.

Can I also revoke certificates this way if my certificate authority has been compromised?

Triggered by the Work by Will Schroeder and Lee Christensen in the summer of 2021 have Discussions developsthat in this way also Certificates signed by bypassing the certification authority, could be blocked.

In principle and from a purely technical point of view, this is correct, but it does not solve the actual problem. If someone is able to sign certificates with the private key of the certification authority, a single certificate revocation helps quite little, since control over the private key of the certification authority is still lost.

If the private key of a certification authority is compromised, in my opinion the only way to return to "secure" operation is to decommission the affected certification authority as quickly as possible, revoking its trust status (at least revoking the certification authority certificate) and completely rebuilding it.

It goes without saying that the underlying attack vectors must have been shut down beforehand.