Issuing S/MIME Digital Certificates with Microsoft AD CS

We will now configure Microsoft Active Directory Certificate Services to issue S/MIME Client Certificates that can be used to deploy S/MIME secure email. For S/MIME secure email, each user must obtain a unique S/MIME Certificate that identifies them. In an S/MIME Certificate, the Subject Distinguished Name field identifies a particular person in the world, as opposed to some server node name. An S/MIME Certificate can be used from any node – it is not tied to a node name as a server certificate is. Note that to use S/MIME secure email, each user must have access to their own private key on every node that they will be using to sign outgoing emails or receiving incoming encrypted emails. In addition, when sending an S/MIME encrypted email, the sender needs access to the current S/MIME Certificate for all recipients of that message. This can be accomplished via a shared address book (e.g., in Active Directory) that contains the S/MIME Certificate for all users. It helps if that shared address book is built automatically as S/MIME Certificates are issued by the CA.

Note that while only one TLS Server Certificate is needed regardless of how many people use that secure server, with S/MIME secure email, every user must be issued a unique S/MIME Certificate that identifies that user. There are several vendors that provide automated systems for providing large numbers of users with S/MIME Certificates, including building a shared address book in AD, and even optional private key escrow. Sixscape Communications provides such a system.

You can export your key material (S/MIME Certificate and private key) in PKCS #12 format and import it on another node (e.g., use your work key material from home or from any other computer). It is possible to import your key material into a hardware token (USB or smart card). If the key material is created inside the token from the start, there is no way to back up the key material (the private key can never be exported from the hardware token). You can move the token (containing the key material) to another computer, but it can only be used from one computer at a time. Alternatively, you can obtain the key material in PKCS #12 form, back it up, and then import the PKCS #12 file into a hardware token (or any number of hardware tokens). This allows you to restore your S/MIME Certificate and create a new hardware token from the PKCS #12 file in the event the original hardware token is lost.

If you are only going to use your key material for digital signatures, there is no need to back up your key material, so it is acceptable to create the key pair and certificate inside a hardware token (a new one with a different key pair can easily be created and used if the current key material is lost). If you are going to use your key material for encryption, then you should back up the key material. In that case, it is not recommended to create the key material and certificate directly inside a hardware token. If the private key is lost, all files encrypted by the corresponding digital certificate are unrecoverable.

We will create a new certificate template for S/MIME Certificates that has only the Email Security flag set and the user’s RFC822 Name (email address) in the Subject Alternative Name.

There are numerous other fields possible in a Subject Distinguished Name, but each item included must be validated by the Registration Authority before the certificate is issued by the Certification Authority. With public CAs, the more fields in your SubjectDN, the more the CA charges for the cert, because most of their cost is in verification of your identity. With AD CS, this verification is done by your PKI administrator.

Create Template for S/MIME Certificate

On the VM running your subordinate CA (in my case, intca.us.hughes.org), in Server Manager, click Tools/Certification Authority. This will start certsrv.

Expand PKIEdu Int CA. Expand Certificate Templates. You should see the following (Figure 16-1).

Right-click Certificate Templates and choose Manage. You should see the following (Figure 16-2)

Right-click User and select Duplicate Template. You should see the following (Figure 16-3).

Click the General tab.

Set the Template display name to S/MIME Certificate. This will change the Template name to S/MIMECertificate.

Set the Validity period to one year.

Select Publish certificate in Active Directory.

It should look like this (Figure 16-4).

Select the Subject Name tab.

Select Build from this Active Directory information.

Select Subject name format as Fully distinguished name.

Select Include e-mail name in subject name.

Under Include this information in alternate subject name, select E-mail name and User principal name.

It should look like this (Figure 16-5).

Select the Extensions tab.

You will see that the Application Policies are currently set to Encrypting File System, Secure Email, and Client Authentication. See Figure 16-6.

Only Secure Email is required. Click Edit.

You should now see the Extension policies. Highlight Encrypting File System and Client Authentication and click Remove. You should now see the following (Figure 16-7).

You should now see the final New Template Properties. See Figure 16-8.

There is now a new template called S/MIME Certificate, as shown in Figure 16-9.

You can now dismiss the Certificate Templates Console (X in upper-right corner).

Prepare for Issuing S/MIME Certificates

In the Certification Authority app, right-click Certificate Templates and select New/Certificate Template to issue. From the list of certificate templates, find S/MIME Certificate. See Figure 16-10.

Select S/MIME Certificate by clicking it, and then click OK. This will enable your new S/MIME Certificate Template to issue certificates.

Now right-click Certificate Templates and select Manage.

Find S/MIME Certificate in the list of templates. Right-click it and select Properties.

Select the Security tab.

You should see the following (Figure 16-11).

Select who you want to be able to enroll S/MIME Certificates (e.g., Authenticated Users), and select Read and Enroll. Click Apply.

It will now look like this (Figure 16-12).

Click OK.

Request and Obtain an S/MIME Certificate Using mmc.exe

The next step is to use mmc.exe to request an S/MIME Certificate for Administrator (the currently logged in user).

Start mmc.exe by selecting Start/Run and entering mmc.exe.

Click File/Add/Remove Snap-in. Select Certificates and then click Add. Select My user account. Click Finish. It should now look like the following (Figure 16-13).

Click OK. Certificates. Expand Personal. Expand Certificates.

You should see the following (Figure 16-14).

Before requesting an S/MIME Cert for Administrator, make sure there is an email account for that user (e.g., administrator@hughesnet.​org). I host the email for hughesnet.org at Rackspace, so I just added a new user there. Alternatively, you could create an S/MIME Cert for any existing email account.

Right-click the middle pane, and select All Tasks/Request New Certificate.

Ignore the Before You Begin page. Click Next. You should now see the following (Figure 16-15).

You should now see the following (Figure 16-16).

Select S/MIME Certificate. Expand Details. See Figure 16-17.

Click Properties. Select the Private Key tab. Make sure the private key is exportable (Figure 16-18).

Click Enroll.

You should now see the following (Figure 16-19).

Congratulations, you have just issued an S/MIME Certificate for the current user (Administrator). Click Finish.

In mmc.exe, you should now see the new certificate (Figure 16-20).

Note that one of them is for Secure Email. Double-click that one to view its properties (Figure 16-21).

It was issued to Administrator.

It was issued (signed) by PKIEdu Int CA.

The ValidFrom date is the date of issue (when I issued this cert).

The ValidTo date is one year from then.

You have a private key that corresponds to this certificate.

Now select the Details tab.

Under CRL Distribution Point, you should see an LDAP URL pointing to your AD server.

This is exactly what you need for an S/MIME Certificate.

Now select the Certification Path tab. You should see the following (Figure 16-22).

The new certificate chains up to the PKI Int CA Intermediate Cert. The PKI Int CA Intermediate Cert chains up to the PKIEdu Root CA Root Cert, which is trusted. This is a three-level hierarchy.

Congratulations! You have just issued an S/MIME Certificate for Administrator.

Test Your New S/MIME Certificate

To test this, you must have Outlook installed on any node in your domain, with an account for [email protected] (or whatever your domain is). In my case, this account is hosted at Rackspace, as an IMAP account. Verify you can send an email to yourself.

If you are not doing this on your Subordinate CA server, you can export the cert and copy it to the node where you have Outlook installed. Alternatively, you can request another S/MIME Cert on the node where Outlook is installed. One way or another, the S/MIME Cert must be on the node where you are running Outlook.

Now configure that account to use S/MIME. This is a bit complicated.

In Outlook, select the File menu. You will see something like this (Figure 16-23).

Click Options at lower left. You will see the following (Figure 16-24).

Click Trust Center at lower left. In the right pane, click Trust Center Settings.

You will now see the following (Figure 16-25).

In the left pane, click Email Security.

You will now see the following (Figure 16-26).

Under Encrypted email, click the Settings button.

You will now see something like this (Figure 16-27).

Change the hash algorithm to SHA256 (SHA1 was deprecated some time ago). Your S/MIME Cert for Administrator was selected (being the only one found).

Click OK. Dismiss the Trust Center dialog with OK. Dismiss the Outlook Options dialog with OK. See Figure 16-28.

Create a Digitally Signed Email

Create a new email (top left corner) to [email protected] (to your account).

In the top menu, select Options. See Figure 16-29.

Click the Sign option and send the message.

In a few seconds, the signed message will appear in your Inbox. See Figure 16-30.

Notice the red ribbon icon in the reading pane. Click it to see details (Figure 16-31).

The signature is valid. The message is from [email protected] and was signed by [email protected].

Click Details. See Figure 16-32.

Click the Signer line (Figure 16-33).

This message was signed by [email protected] on 11/21/2021.

Click View Details. See Figure 16-34.

Click View Certificate. See Figure 16-35.

Send a Digitally Enveloped Message

To do this, we need to capture our digital cert in a contact. In the reading pane, right-click the recipient, and select Add to Outlook Contacts. You will see the following (Figure 16-36).

Click Show/Certificates (Figure 16-37).

You can see that it captured the certificate from the signed message in our Outlook contacts.

Click Save and Close.

Now create another new email (Figure 16-38).

Click the To button. See Figure 16-39.

The administrator contact we created is now there. Click the To button at the bottom to use it as the recipient.

Click OK.

Add a subject line and message (Figure 16-40).

Click the Options item in the top menu. Select both Encrypt and Sign. See Figure 16-41.

Send the message. If the send fails, it didn’t find the recipient’s certificate.

Assuming everything went well, the new message will appear in your Inbox (Figure 16-42).

Note the new message in the reading pane has both the padlock (encrypted) and seal (signed).

Click the padlock icon (Figure 16-43).

There are now both Encryption and Signature layers.

Click Details. See Figure 16-44.

Click the Encryption Layer. See Figure 16-45.

The message was encrypted using AES256, for [email protected].

Now click the Signer line (Figure 16-46).

The message was signed by the sender, using RSA/SHA256.

You can see the signer’s certificate via View Details as before.

As you can see, we have created a valid S/MIME Certificate using Active Directory Certificate Services and sent both signed and encrypted emails using it.