Skip to main content

Secure Socket Layer (SSL) Certificates for Stanford.edu

Action required by June 30, 2026
InCommon has announced a transition from Sectigo to a new certificate authority, CERTInext. Stanford domains that request or renew SSL/TLS certificates through InCommon will need to be validated in CERTInext by June 30, 2026.

An SSL certificate is a signed electronic guarantee that verifies the authenticity of a particular server. It's primarily used for providing web pages through an encrypted connection. Any service accessible by SSL must have a certificate, including any web server with encrypted or “secure” content.

Sometimes a self-signed certificate is sufficient for test and development servers, and it works with SSL encryption. See the instructions for creating a self-signed certificate for more information. However, self-signed certificates don't help confirm the server's authenticity, and they could be open to some attacks. Most clients display a warning when they connect to a server with a self-signed certificate before proceeding (and some won't work at all).

You should use an SSL certificate signed by a trusted certificate authority on servers that require an encrypted connection. Stanford provides SSL/TSL certificates for eligible Stanford domains through the InCommon certificate service. There is no longer a cost to Stanford users. Stanford works with InCommon to provide SSL/TLS certificates for eligible Stanford domains at no additional cost to Stanford users. InCommon has announced a transition from Sectigo to CERTInext, and Stanford certificate processes are being updated as part of that transition.

Designed for

Current faculty and staff; system administrators in academic and administrative departments.

Requirements

To request a certificate for a given hostname:

  • The name must exist in NetDB.
  • The requester must be listed as a user, administrator, or administrative group member in the host name's NetDB record.

Note: If you do not have a NetDB account, you can check if the name exists using StanfordWhat.

Data security

SSL certificates are required for all web servers with encrypted or High Risk Data. Please review the information on Moderate and High Risk Data, as defined by the Information Security Office.

Rates

Free of charge.

Get started

To obtain an SSL certificate, you must first generate a CSR (Certificate Signing Request). This file contains the required technical information to generate an SSL certificate.

To request a certificate, follow these steps:

  1. Generate a CSR. You can generate a CSR in multiple ways. Your server software may have a built-in function that creates the private key and CSR for you, but in most cases, you should use the OpenSSL command-line utility to create them (see instructions). For more information, read the InstantSSL instructions and choose your server from the links on their page for specific guides. Note that all the hosts listed in your CSR must be registered in the NetDB system.
  2. Note: The service supports 2048/3072/4096-bit keys. 3072-bit keys is recommended as of November 2023.
  3. Store your key in a safe and secure location. 
  4. Complete the online request form.
  5. You should receive your certificate within 2 business days.

After InCommon issues your certificate, you'll receive a confirmation email through an Administrative Systems administrator. The message contains several links to the certificate in different file formats (the first link contains the most common format) along with a link to a file that contains the root and chaining certificates (combined in one file) used to sign your certificate.

Note: Domains must be validated in CERTInext before new certificate requests or renewals can be completed through InCommon/CERTInext.

Renewals

The process for certificate renewal is exactly the same as for ordering a new certificate. You must create a CSR and submit the request form.

Get help

For assistance, please submit a Help request.

Learn more

See also

Last modified