Export (0) Print
Expand All

General PKI Planning Considerations

 

Topic Last Modified: 2006-08-16

Regardless of the specific e-mail clients and PKIs implemented as part of your Exchange 2003-based message security system, there are some general considerations that all PKI administrators should consider when planning their deployment. You should understand the issues surrounding digital certificates and Active Directory attributes.

Microsoft e-mail clients that can be used with an Exchange 2003-based S/MIME system rely on Active Directory for digital certificate storage. Other e-mail clients can be configured to use Active Directory through LDAP interfaces. To use Active Directory effectively with these different e-mail clients, you need to understand the attributes that Active Directory makes available for storing digital certificates. The PKI administrator should confer with the e-mail client administrator, and then formulate a comprehensive strategy for storing digital certificates in Active Directory.

There are two different attributes available in Active Directory for digital certificate storage: userCertificate and userSMIMECertificate. You need to understand which attributes the specific e-mail client uses, and the order in which it will query these attributes for valid digital certificates. If both attributes contain valid certificates, different e-mail clients can return different digital certificates for the same user.

importantImportant:
Outlook and Outlook Web Access with the S/MIME control each look first to a different Active Directory attribute when performing a search for digital certificates. If a user's Active Directory attribute has valid certificates for both attributes, a user will experience difference results when using Outlook and Outlook Web Access with the S/MIME control. For more information, see Troubleshooting S/MIME in Exchange Server 2003.

You should determine which single attribute to use for digital certificate storage and use only that attribute. In most cases, this attribute will be the userCertificate attribute. In addition, when deciding on a single Active Directory attribute for storing digital certificates in support of S/MIME, if there is an existing Active Directory deployment, check the contents of Active Directory and remove any outdated or unauthorized digital certificates. For a sample Visual Basic® script that can be used to search for and delete these existing digital certificates, see Digital Certificates Cleanup Script.

The userCertificate attribute (also referred to as X509-Cert) in Active Directory stores DER Encoded X.509 v3 certificates that are associated with a user. This is the attribute in which Windows Server 2003 CA publishes any certificates that it has issued for that user. When using Windows Server 2003 to generate S/MIME certificates, this is the attribute where those certificates can be found. The contents of this attribute can be viewed through the Published Certificates tab when looking at the user's object in Active Directory Users and Computers.

Although Windows Server 2003 CA uses this attribute, it can also be used to store digital certificates issued by other certificate servers with a PKI. The userCertificate attribute is the preferred attribute when S/MIME is implemented as part of a PKI. Because S/MIME will be used with a broader PKI deployment, this attribute should be the preferred attribute for storing digital certificates.

Outlook Web Access with the S/MIME control looks to this attribute first to give preference to the organization's PKI.

The userSMIMECertificate attribute stores a digital certificate in PKCS #7 format. Unlike userCertificate, which stores any X.509 v3 certificate, this attribute was designed specifically to store only S/MIME certificates. This attribute, which was specified as part of the InetOrgPerson class in RFC 2798, facilitates using S/MIME outside of a PKI. For more information, see "Definition of the inetOrgPerson LDAP Object Class" (http://www.ietf.org/rfc/rfc2798.txt). The userSMIMECertificate stores not only the certificate but the full certificate chain. This makes it possible for a user to validate a certificate without having direct access to the PKI that issued it.

In general, you will not want to use this attribute in your environment.

This attribute is not accessible through Active Directory Users and Computers. It is possible to publish a digital certificate to this attribute through the Publish to GAL button in Outlook. If you decide not to use this attribute, disable this button to prevent users from inadvertently publishing inappropriate and unauthorized certificates to Active Directory. For more information about the Publish to GAL feature and how to disable it, see Supporting Outlook in Your PKI.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft