The University of Maine System has access to InCommon for SSL (and TLS) certificate signing. InCommon is a service provided by Internet2 through Sectigo which allows UMS to have unlimited certificate signing services for an annual fee. There is no per-certificate cost.
Detailed Information
INFO: As of October 2021 we recommend the use of ECC (Elliptical Curve Cryptography) encryption with a key size of 384 versus RSA (Rivest–Shamir–Adleman). ECC is more secure and, as it generates smaller keys, is faster and requires less network load.
Request Process
To have an SSL certificate signed, generate a valid CSR and create a new service request ticket in TDX. Chose "SSL Certificate Management" as the service and "IT Sys Admin" as the "Responsible" person. Make sure to attach the CSR. Please provide the following information with your request:
- The domain(s) for the certificate.
- If the cert is multi-domain or wildcard. If not specified, we will assume single domain.
For certificate renewals you do not need to generate a new private key or CSR. Sending a renewal request with the domain(s) for the certificate to the above contacts will suffice.
Generally new keys are required only for new certificates, or if the old key is lost or compromised.
Likewise, generally CSRs are generated only for new certificates, if a new key was generated, or if any of the certificate information needs to be changed (e.g. the CN value).
How to Generate a CSR
Step 1a: (ECC, recommended): Generate a private key
The recommended key size for ECC is 384 which is equivalent to RSA 7680.
The preferred method to generate a private key is using OpenSSL. The following commands should be sufficient for most applications.
openssl ecparam -genkey -name secp384r1 -noout -out server.key
DANGER: Do not share the .key file, as this is the private server certificate.
Step 1b: optional (RSA, legacy): Generate a private key
An modern SSL certificate should be a minimum of 2048-bit in length and make use of SHA-2 for it's signature cipher rather than SHA-1 as Google and other major browsers plan to mark SHA-1 certificates as invalid starting as early as 2015.
The preferred method to generate a key is using OpenSSL. The following command should be sufficient for most applications:
openssl genrsa -out server.key 2048
Step 2: Generate a CSR (certificate signing request)
Generate a CSR using your private key (if upgrading from RSA to ECC you will have to generate a new EC private key versus reusing your existing RSA key):
openssl req -key server.key -out server.csr -new
OpenSSL will prompt you to answer some questions for the certificate. It is important that you fill this information out correctly. Everything but the CN value (which should be used to access your service) should be completed as shown below (e.g. the state should be Maine not ME, password should be blank).
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:Maine
Locality Name (eg, city) [Newbury]:Orono
Organization Name (eg, company) [My Company Ltd]:University of Maine System
Organizational Unit Name (eg, section) []:Information Technology
Common Name (eg, your name or your server's hostname) []:example.maine.edu
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Add the contents of the CSR file to your open ticket.
WARNING: If it seems the private key material is submitted with the request material, your request will be rejected and you will need to repeat the steps to generate a new (secured) key.
Once the certificate has been signed, you will receive an email from InCommon with several download links of the certificate and certificate chain in various formats. For a standard Apache web server, there will be two relevant downloads:
The first download will be the public certificate. Use the X509 Base64 format (certificate only) link. You can rename it to have a .crt extension, e.g. server.crt.
The second download will be the certificate chain file. Use the X509 Base64 format (intermediates only) link. This can be renamed to server.ca-bundle (note these names only matter to the extent that you correctly reference them in configuration).
Step 3: Installing the signed certificate (Apache Example)
Typically, SSL websites are placed within a VirtualHost configuration stanza. Within the stanza, reference the 3 files as follows:
SSLEngine on
SSLCertificateFile /srv/example.maine.edu/ssl/server.crt
SSLCertificateKeyFile /srv/example.maine.edu/ssl/server.key
SSLCertificateChainFile /srv/example.maine.edu/ssl/server.ca-bundle
Step 4: Hardening Your Web Server (Apache Example)
Take note if enabling SSL on Apache for the first time, there are a number of steps that should be taken to harden Apache from legacy ciphers and protocols:
At a minimum, SSL should be disabled (in favor of TLS). Comment out the SSLProtocol line and replace with the following (or similar).
SSLProtocol All -SSLv2 -SSLv3
Also recommended is to update the supported cipher list to disable RC4 and other weak ciphers. Comment out the SSLCipherSuite line and replace with the following (or similar).
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
SSLHonorCipherOrder On
Note: The above list provides backwards compatibility support up to IE6. The Mozilla Foundation maintains a comprehensive write-up on recommended ciphers and known vulnerabilities at: https://wiki.mozilla.org/Security/Server_Side_TLS
You should also disable SSLCompression to mitigate the CRIME attack.
SSLCompression Off
In addition to SSL configuration, you should also harden your Apache configuration to disable server signatures and TRACE requests, and limit server tokens.
ServerTokens Prod
ServerSignature Off
TraceEnable Off
Certificate Revocation
Should you believe a certificate has been compromised or the certificate is no longer needed you can revoke the certificate so that it can no longer be used. Requests for this service can be submitted just like requests for new certificates. Create a support ticket in the SSL project. You will need to send some information on how to tell which certificate to revoke. The name on the cert and either the serial # or the start and end dates should be enough to identify it.
Environment
- InCommon
- SSL/TLS certificates