SSL Certificates for stanford.edu
Introduction
An SSL certificate is a signed electronic guarantee that a particular server is the server it is claiming to be. They are used primarily (but not exclusively) as part of providing web pages via an encrypted connection. Any service accessible via SSL has to have a certificate, including any web server with encrypted or "secure" content.
For test and development servers, it's often sufficient to use what is called a "self-signed" certificate. This type of certificate is sufficient for use with SSL encryption, but doesn't help confirm the authenticity of the server and may therefore be open to some attacks. Most clients, when connecting to a server using a self-signed certificate, will display a warning before proceeding (and some will not work at all).
Publicly accessible, production web servers therefore generally use an SSL certificate signed by one of a few certificate authorities who are trusted by SSL clients (including web browsers). Stanford has historically primarily used Verisign certificates, but starting in 2003 has contracted with InstantSSL to provide SSL certificates for stanford.edu systems. InstantSSL is considerably less expensive than Verisign.
Known Issues
There are a few known issues with using the much less expensive InstantSSL certificates instead of Verisign certificates:
InstantSSL certificates are not signed directly by one of the certificate authorities trusted by browsers. Instead, they are signed by a certificate authority that is then signed by another trusted certificate authority. For the most part, this doesn't matter, but it does mean that there are some additional required steps when using a certificate with an Apache server.
InstantSSL certificates are not trusted by Java versions prior to 1.4.1. See our older Java client documentation for information on how to deal with this.
InstantSSL certificates may not also be trusted by various older versions of other servers and software packages. In some cases, this can be remedied by importing the GTE CyberTrust root certificate into the application's credential store. In other cases, a certificate from another vendor may be required until the application can be upgraded. We therefore encourage anyone who is using certificates for applications other than Apache or IIS web servers to get an InstantSSL certificate somewhat in advance of the expiration time of their current certificate so that they have adequate time for testing.
The maximum key size supported by InstantSSL is 2048 bits. For the best security, we recommend using this size when generating your CSR.
Getting an SSL Certificate
In order to obtain an SSL certificate, you will need to be able to provide a university account for charging and an authorized approver for the transaction. You will also need to generate a Certificate Signing Request (CSR) for your application, which is a file that contains the required technical information to generate an SSL certificate.
An SSL certificate for 128-bit encryption that expires in one year costs $40. Multi-year certificates are also available at a discounted rate. A two year certificate costs $75. Each SSL server requires a separate certificate.
To request a certificate, follow these steps:
Generate a CSR. If you have not done this before, here are the InstantSSL instructions for generating a CSR. Choose your server from the links on the side of their page for specific instructions.
Once you have your CSR you can then fill out the online request form:
Request a new SSL certificate
Your certificate request will be processed by InstantSSL and you will receive your signed certificate in the mail at the contact e-mail address you listed on the form.
Installing the SSL Certificate
To install your certificate, once you receive it in the e-mail, follow the InstantSSL installation instructions. Again, choose your server from the available options on the side of their page, and if you have any trouble, please submit a HelpSU request using the link at the bottom of this page.
