SSL Certificates

Overview

SSL certificates serve two important functions. First, they permit communication with a web server to be encrypted. Web servers commonly use encryption to protect private data, such as passwords. Second, SSL certificates allow visitors to validate the website they're communicating with is authentic (and not, for instance, a malicious copy intended to trick visitors into disclosing passwords).

Recommendations

The following are the Berkeley Lab recommendations for SSL certificates  

• InCommon one year certificates are free, issued nearly instantly, and recommended for most cases, visit https://certificates.lbl.gov. 
  
  
• Let's Encrypt certificates are recommended for Linux/UNIX computers using Apache and accessible from the Internet (e.g. Registered Web Servers). The automated renewal process makes these certificates particularly attractive. 
  
  
• If you previously got an SSL Certificates from GoDaddy, that process was deprecated in Aug 2019.  Any CSR requests with GoDaddy will be denied by default. 

InCommon

Berkeley Lab has subscribed to the InCommon SSL certificate service. This allows Lab employees to acquire one year Sectigo certificates (was Comodo) easily via a simple web interface at https://certificates.lbl.gov. 

These certificates can be issued for lbl.gov and nersc.gov. No wildcard certificates are allowed. If you have questions or need a certificate for another domain, please contact [email protected]. 

We recommend you setup the InCommon intermediate certificate chain (Intermediate(s)/Root only) so that Firefox can validate the certificate. 

Process

1. Generate a Certificate Signing Request (CSR), there are various how to articles are https://help.comodosslstore.com/support/solutions/folders/22000168634
2. Visit https://certificates.lbl.gov, paste in the CSR, select a "Server type", and click "Submit CSR". 
3. On the next screen verify the information and select "Complete".
4. After a few minutes, both the requestor and the DNS contacts will receive an email such as the one shown below. 
   
   
   
   
5. The certificates can be downloaded from that email. In most cases, one only needs "X509 Certificate only, Base64 encoded"

More information

Our colleagues at UC Berkeley are using the same service.  Consider reviewing their more fully developed FAQ for more information. 

https://calnetweb.berkeley.edu/calnet-technologists/web-certificates#General

Let's Encrypt

Let's Encrypt provides free SSL certificates that are trusted by all major browsers. Let's Encrypt validates domain ownership directly with the web server via the ACME protocol.  Web servers typically install a ACME client, such as Certbot to facilitate this process. 

Limitations

Let's Encrypt currently has several limitations that prevent wide spread adoption in the LBNL environment. 

• The maximum lifetime of a certificate is 90-days, so you need to put a process in place to facilitate frequent updating. There are situations in which this is not possible, for example appliances that do not allow OS access or arbitrary code.  Another example, the application environment, such Java/Tomcat need to be restarted to use a new certificate. 
• The renewal process requires the web server to be accessible to the Internet. There are cases where SSL certificates are in use where Internet accessibility is not desirable.

Recommendations

We currently only recommend Let's Encrypt for limited situations when the web server is on a Linux/UNIX computer using Apache and accessible from the Internet (e.g. Registered Web Servers). Additionally, we recommend the following configuration.

• Set automatic renewal of certificates every 60 days
• Use Certbot with Simple HTTPS validation (requires root access)

For all other situations, we continue to recommend  https://certificates.lbl.gov.

Pre-implementation

Before you can setup Let's Encrypt, you must have 80/tcp accessible from the Internet.  You can submit a Open a Web Server to the Internet to just open 80/tcp for this purpose. This will be a temporary registration to enable Let's Encrypt. The web server must pass a full vulnerability scan before the registration is made permanent. 

Overview of getting a Let's Encrypt certificate with Certbot

Requirements:

• Certbot presently only runs on Unix-like OSes
• Python 2.6 or 2.7
• root privileges
• http or https access

Step 1: Make sure your server is accessible

• Check firewall configuration
• Make sure your webserver is listening on port 443
• Make sure your webserver is accessible from the Internet (e.g. Registered Web Servers)

Step 2: Download the client

Go to https://certbot.eff.org/. Select the type of webserver you are running and the operating system it is on. Some systems will have packaged versions of certbot while some will require you to download a script. The two are functionally the same and take the same arguments

Step 3: Install the package or script

These will vary slightly depending on the server and operating system. Follow the instructions for your system.

Step 4: Request a certificate

For example, on Ubuntu 16 running an apache web server:

sudo letsencrypt --apache

First select the host you want to get a certificate for. Then select if your machine will be using HTTP and HTTPS or just HTTPS.

Note: This process searches your apache configurations for hosts. Sometimes hosts aren't found if multiple virtual hosts are defined in the same conf file. The name can be manually entered with the --domains domain.name flag if this occurs.

Step 5: Automate renewals

Add the following command as a cron or systemd job:

letsencrypt renew

Additional details and Alternatives

Our documentation is just an outline, there is detailed documentation on this process at https://certbot.eff.org/

There are literally dozens of other ACME clients one could use to perform the domain validation. 

We continue to follow this technology and as other domain validation methods appear (such as DNS in a way we can automate at LBNL) we will update this documentation.

There are many hosting providers that support Let's Encrypt. Some even simplify the process through their cPanel. Check with your hosting provider for Let's Encrypt support and the installation process for third-party certificates. There are all also many third-party acme clients to make installation in certain environments easier.

Self-Signed Certificates

It is also possible to create 'self-signed' certificates. A number of web sites describe the process of creating such certificates. Self-signed certificates are only recommended in certain situations, such as development, testing, or when web site access is restricted to a small population. The problems with self-signed certificates is they are not trusted by browsers. When a modern browser encounters a self-signed certificate, the browser tries to protect the end user. The browser presents the user with a number of prompts requiring him or her to recognize the risk of the unknown certificate, examine the certificate, and accept it. If a user frequently encounters self-signed certificates, however, it's almost inevitable that he or she will begin to accept them without examination. One day, the user may visit a malicious site, but he or she will probably ignore the warnings.