Included on this page:
The UW Services Certificate Authority (CA) issues certificates for various kinds of services, the two most typical being:
In general, it issues certificates for secure web servers and other kinds of SSL-secured services, such as email servers (IMAP, POP, etc). It also issues certificates for services that need to access other secure services, such as a web server that needs to access a secure directory.
Certificates issued by the UW Services CA are appropriate for many uses and applications, but not all applications. A key issue is that the UW Services CA root certificate is not installed in browsers by default, which can increase support costs associated with the use of UW Services CA certificates. While many other CA root certificates are pre-installed, the UW Services CA root certificate must be installed by the user (see section 1.4 on getting the root certificate) or by automated desktop configuration strategies (e.g. Windows group policy). Many UW users have installed the root certificate in their browsers, but most users outside of UW have not.
For this reason it is not advisable to use UW Services CA certificates on web applications with large numbers of users (10,000 or more), or where many users are not from the regular UW community. Web applications using UW Services CA certificates with more than a small number of users (over 100) should have support staff who can help users with any questions that may come up about certificate warnings and use.
A certificate issued by InCommon may be an appropriate alternative for securing applications whose scope exceeds that supported by the UW CA. The new UW Certificate Service website supports issuing InCommon certificates in addition to UW CA certificates. Please see the UW Certificate Services page for more information on the two certificate authorities.
Administrators should weigh several factors before choosing the UW Services CA over other well-established public CAs, particularly when SSL-enabling a web server. These factors include:
Users who haven't installed the root certificate into their browsers will see warning messages when your web server presents a certificate issued by the UW Services CA. If you don't help them install the root certificate beforehand, visitors may think there is a problem with, or become frustrated by, your website.
Although pre-installing the root certificate on systems within your department that you manage can significantly reduce the support burden, it probably won't eliminate it. Therefore, if you plan to deploy a certificate issued by the UW Services CA you should be prepared to support your user community and answer some questions (see UW Services CA FAQ).
If the size and nature of your user community suggests that this support is going to be difficult, it might be better to purchase a certificate from a well-known public CA, such as Thawte, and wait until such a time that the UW Services CA root certificate is better deployed within your user community. An InCommon-issued certificate may also be a good option in some cases.
The UW Services CA's root certificate can be obtained by visiting the UWCA site website to obtain it in PEM or DER format.
The UW Services CA issues service certificates quickly and automatically to contacts of DNS names with UW NetIDs registered in the Domain Name Service maintained by UW Technology. The certificate request process depends on the purpose of the certificate:
To request a certificate for a system with a DNS name and an assigned static IP address:
<hostname>.<subdomain>.washington.edu or <appname>.<subdomain>.washington.edu) and click "Verify ownership." If the response confirms your ownership, go to the next step. Otherwise go back to step 1.Note: If your DNS name is not in a DNS subdomain managed by UW Technology, your subdomain contact will have to submit and manage the certificate request.
To request a certificate for a service, application, or process without an assigned static IP address:
<application name>.<subdomain>.washington.edu). Application developers working with web services will often request a DNS name of the form <uwnetid>.<subdomain>.washington.edu.The UW Services CA asserts several keyUsage extensions if they are specified in a given certificate signing request: Digital Signature, Non Repudiation, Key Encipherment, and Data Encipherment. If you need a certificate with any of these keyUsage extensions, generate and submit a request including those extensions you need. (See Section 4.2.1.3 of RFC 3280 to learn more about keyUsage extensions.)
Note: Don't include keyUsage extensions unless you are certain you need them. Under usual circumstances you will be better off without them.
The UW Services CA asserts all Subject Alternative Name (subjectAltName) extensions specified in a request if you are a registered contact of each name in UW DNS. The issued certificate contains each subjectAltName you specify, plus the value of the request's CN element as a subjectAltName if it wasn't already in the list.
The UW Services CA manages certificate requests using contact information from the Domain Name Service maintained by UW Technology. Registered contacts for your DNS name can request changes. For help, refer to Managing DNS Names For Infrastructure Services Access
The UW Services CA notifies all registered contacts for your DNS name when your certificate is approaching its expiration date. This expiration notification is sent via email approximately a month before expiration.
Note: The UW Services CA discards requests corresponding with expired certificates about a month after the expiration date. At that time, you will no longer see the request and certificate listed in the management interface and you will have to generate and submit a new request to obtain a new certificate.
You should only revoke a certificate if you have reason to believe its private key has been stolen and could be misused. Please do not revoke a certificate just because you do not want an application to accept the certificate any longer. Instead, please remove the certificate's access rights to the application. Each revoked certificate becomes listed on the UW Services CA Certificate Revocation List (CRL) which is downloaded and checked several times a day by multiple systems. Keeping the CRL short reduces resource utilization on all the systems.
Email help@uw.edu with the CN (DNS Name) and expiration date of the certificate.
Hosting multiple applications on the same server introduces a dilemma: should you use one certificate for all the applications or one certificate for each application?
As a guideline, use distinct certificates when the applications or processes using certificates for access to other services have a distinct function, or distinct administration, or are likely to need different levels of access. A rule of thumb might be if you would run the processes under different local accounts or userids, then you should use distinct certificates.
The UW Services CA supports wildcard certificates. To request a wildcard certificate you must be a registered contact for the UW DNS subdomain specified in the request's Common Name field. For example, to request a certificate for *.<subdomain>.washington.edu you must be a subdomin contact for <subdomain>.washington.edu.
SHA-1 certificates for legacy applications can be requested by sending email to help@uw.edu. SHA-1 Support will be reduced over the next few years–see UW CA SHA-1 Sunset for details.
The common usage of "client-server" in networking terminology defines the client as the initiator of a connection and the server as the target system of that connection.
A server (such as a web server) can provide a server certificate to a client during secure SSL connections. This server certificate contains information that the client can verify so it can trust the host it has connected with is the desired server. For example, the web servers for _https://www.washington.edu_ have server certificates to indicate they are authorized to use that DNS name. Server certificates also allow a client to send encrypted data to the server which only that server can decrypt.
Client certificates can be used to identify the client to the server. They provide the server with verifiable information about the client. Note the term "client" is not clearly defined; it may identify and authenticate a system or service, a user, or even a process running on a machine. The UW Services CA currently issues client certificates for system and service identification only, based on DNS names.
UW Services CA certificates can be used either as client or server certificates, but only to identify systems and services with DNS names. The UW Services CA does not issue certificates used to identify people.
Here are some considerations if you are verifying a UW Services CA certificate used within client authentication:
On Windows 2000 and Windows XP, certificates can be stored in a variety of locations. The various storage locations are not equivalent, and a certificate must be stored in the proper location for its intended use or else it won't be usable.
The Windows operating system itself provides several significant certificate storage locations. Applications such as IE and IIS use these locations for certificate storage and retrieval. The locations include a separate User Store for each user account, as well as a Local Machine Store for the computer's system processes. Both stores have numerous sub-folders which contain the actual certificates of varying types.
The User Store typically contains certificates that a user can use to authenticate to web servers. It may also contain certificates that can be used for S/MIME, encrypting files, signing software, etc. These certificates are usually located in the Personal subfolder of the User Store.
To display the current User Store, run certmgr.msc. This program includes help information that explains certificates and stores in detail. Note: this tool's utilities to "request a certificate" cannot be used with the UW Services CA because it is a standalone, third-party CA. This feature only works with Active Directory Integrated Microsoft Enterprise CAs.
The Local Machine Store (also provided by the Windows operating system) contains certificates that identify the machine to other machines. The Windows operating system uses these certificates to serve web pages with SSL, negotiate IPSEC, etc. These certificates are usually located in the Personal subfolder of the Local Machine Store.
Using the MMC with the Certificates add-in allows you to choose the Local Machine store for viewing. You must have local Administrator rights on the machine to do so.
Applications may also provide their own certificate stores and tools to manage them. Examples would include Sun's Java VM which uses its own store and is managed with its keytool application. Netscape software also uses its own certifcate storage and provides a manage UI for it. Please refer to specific application documentation to understand these non-OS based certificate stores and how to use their own tools to manage them.
If a certificate is created with an exportable private key, you can use the certmgr and/or MMC GUI tools to export the certificate to a different storage location. Right-click the certificate and choose All Tasks > Export...
If a certificate is created with a non-exportable private key, you can export the public key of the certificate, but not the private key.
To import a certificate, double-click the .crt file, and select which store for installing the certificate. UW Services CA certificates are typically placed in the LocalMachine/Personal store, so if you want to use one as a client certificate, export it using the mmc and then import it into the "user/personal" storage location.
To add the UW Services CA root certificate to a Windows domain's group policy:
The new CA root certificate should now be visible in the Group Policy Editor/Viewer, and machines in the affected OU will have and trust the new root certificate after a group policy refresh cycle (usually 24 hours, or after their next reboot).
To request a certificate for use with IIS using the IIS's Web Server Certificate Wizard:
Note: the following instructions were tested on a Windows 2000 Server SP4, with Internet Explorer 6.0.2800.1106, and all critical updates as of 29 Apr 2004. Be sure your system has all critical Windows updates and IE updates installed by visiting Windows Update.