Enabling SSL (HTTPS) On Your JHU Website Not Hosted By CS IT

Revision as of 19:47, 7 April 2022 by Phil (talk | contribs) (→‎Additional Notes)

INTRO

To enable SSL for your non-CS hosted website (but, hosted on a JHU network), that is, to enable HTTPS for your site:

Visit JHU's official website for requesting an SSL certificate.

General Summary Of What You'll Be Doing

  • Generate an SSL public and private key pair
  • Generate a certificate signing request (CSR) from that key pair.
  • Request a Certificate from JHU at https://login.johnshopkins.edu/comodo:
    • Paste the contents of the CSR into the form
    • Select the type of web server you're using
    • Enter a contact email address (we recommend using a team email address that will go to whoever is responsible for your website.)
    • Submit the form.
  • Wait.

After a while (usually, a few hours, but sometimes as much as a day), you'll receive a set of emails. One of the emails will have links to your certificate. For most cases, you'll need the certificate file and the intermediate certificate chain. The chain should be in reverse hierarchical order; if you gave a server type that uses X.509 certificates, it'll be the link in the email labeled "X509 Intermediate(s)/Root only".

Then you just need to save the certificate and chain in a place where the server can see them and reconfigure the server.

NOTE: Depending on the server, you might have to have the certificate and intermediate chain in separate files, or you might concatenate them (with the certificate first) into a single file.

Additional Notes

1. Multiple Website Names: If the website has multiple names, you need to create a CSR with one common name (CN) and one or more subject alternate names (SANs). How you do that will vary depending on the programs you're using. In case you're using OpenSSL on Linux, this page seems reasonable:

https://geekflare.com/san-ssl-certificate/

Basically, you copy your openssl.cnf file, add this to the [req_ext] section: 

subjectAltName = @alt_names

and then add an [alt_names] section with the extra names enumerated, e.g.: 

[ alt_names ]
DNS.1 = www.dsn.jhu.edu
DNS.2 = dsn.jhu.edu

and so on.

The CN should be whatever is the "main" hostname for the site. Ideally, the other domains should issue redirects to send clients to the main site. That's good practice and can help with SEO.

2. Obtaining Multiple Certificates: If you are using Apache HTTPD just put different SSLCertificateFile and related configuration entries into each site's VirtualHost block, with each one referencing that hostname's certificate.

However, we recommend to get just one certificate with SANs. It makes things easier to manage.

3. Configuration Generator for SSL Servers: Mozilla has a very nice configuration generator for SSL servers:

https://ssl-config.mozilla.org/

You tell it what software you're using and what version you're running, and it will give a recommended set of configuration settings for using good encryption. We recommend using their Intermediate configurations. Modern tends not to be great for public websites, and Old trades a little security for compatibility with very old clients that most people don't need to worry about.

4. HTTP Strict Transport Security: If you want to use HTTP Strict Transport Security, make sure your SSL setup is working *before* you enable HSTS! Once you turn on HSTS, browsers will refuse to use HTTP for your website, even if HTTPS doesn't work.

5. Testing Your SSL Configuration: You can test your SSL configuration with either the online Qualys SSL Server Test:

https://www.ssllabs.com/ssltest/

Or by downloading and running testssl.sh:

https://testssl.sh/

Both tools check for a variety of things, including secure use of encryption and resistance to know security vulnerabilities. If a tool flags something as a problem it's worth learning about why it's a problem and what you can do to fix it.

Final Recommendation

It's a good idea to enable HTTPS for any website you host. If you just use HTTPS by default (and redirect all HTTP traffic to HTTPS), you'll never accidentally have a page unencrypted when it should have been encrypted. Not every website *needs* HTTPS, but it's often less work to get and maintain SSL certificates for a site than it is to verify that every single page it serves is okay being unencrypted.