Two ways to install root certificates into Internet Explorer
Certification Authorities (CA) that issue End Entity (EE) client certificates typically provide the whole certificate chain at the same time that they deliver the user's client certificate. The chain includes the user's EE certificate, any intermediate certificates in the path, and the root certificate. The overall client certificate request and delivery process is usually a multi-stage event that is carefully documented by the CA with appropriate answers well scripted for the users. Users are motivated to take the time needed to read the documentation to obtain their client certificates and thus be able to use PKI-enabled applications.
Along with issuing client certificates, many campus PKI projects are also planning to issue SSL server certificates to campus computers in order to reduce costs. Campus issued SSL server certificates are often made available at no cost to user departments. One problem with the use of campus-issued SSL certificates is that the campus root certificate must be installed into every user's browser. This problem is likely to be significantly different from the EE certificate download case above since a campus is not likely to issue identity certificates to all users in the early stages of their PKI activity but may need all users to have their root certificate installed to support the SSL server certificate component of the project. The easier the root certificate installation process, the more likely that the campus issued server certificate program will be successful.
Case 1 below shows the mechanism that most campuses have been using to
distribute root certificates to their users. This mechanism supports
both Internet Explorer and Netscape but is relatively cumbersome and
prone to user error. Case 2 only works with Internet Explorer
but is much easier for the average user to complete successfully. Since
a large majority of users prefer Internet Explorer, it may be worth the
effort to detect the browser type and use the mechanism described in
Case 2 for root certificate installation into Internet Explorer.
Case 1: Using the DER-encoded form of the certificate and the proper MIME type
Simply placing a link that points to the DER-encoded version of the certificate is the most common mechanism used to distribute root certificates for download. An example using theCrenRoot.crt is a file on Web server's disk containing the
DER-encoded form of the certificate. You must also ensure in this case
that the Web server is configured to map the file extension
.crt to the proper MIME type of:
application/x-x509-ca-cert
When a user clicks on the link above they will first receive the
standard file download dialog box. Once the user has specified to open
the file from its current location, they will be placed into the
certificate import wizard shown at the left. The key to a successful
import is for the user to somehow know to click the Install
Certificate button instead of the OK button. Simply
clicking OK appears to be natural for most users and the
certificate installation fails silently. If the user does click the
Install Certificate button, they will go through a five or more
step wizard depending on the Operating System version and patch level
to actually install the root certificate. In some cases the user will
be prompted to delete an existing copy of an already loaded root
certificate before the new one can be installed. In other cases the
operating system will determine that the user is simply attempting to
reinstall a root certificate that is already in the certificate store
and will silently complete the process without alarming the user.
Case 2: Using PKCS-7 and the Microsoft Certificate Enrollment Control
Another way to deliver a root certificate is to use the Microsoft Certificate Enrollment ActiveX control. This is the same control that is normally used to accept a user's new EE client certificate and its associated certificate chain but is called with different parameters. The main advantage to this download mechanism is that its much easier for a user who knows little about PKI to correctly install the root certificate. Only one or two dialog boxes appear depending on the version of Windows and the patch level of the system. The correct user response to these dialog boxes is always yes instead of some of the more cumbersome and difficult to document responses of Case 1 above. This mechanism is a little harder to implement in the CA but it makes it much easier for the average user to correctly download and install your root certificate. Note that users must not have disabled browser scripting or ActiveX controls for this mechanism to work. ActiveX and scripting are enabled by default but some users may configure their systems to disable these features.
Click here to download and install the
CREN root certificate via the CEnroll control.
Click here to see the source code for the installation demonstration above. The use of this technique in a production environment would most likely involve a little more complex script but all of the basic components are shown. The credentials constant is the base 64 encoded version of the CREN root certificate contained in a PKCS-7 object. Thanks to Ken Ruggaber at Virginia for the code fragment to implement the download and Jeff Schiller at MIT for the code to correctly instantiate the CEnroll object on computers with and without the patches for Q323172.