Body
Statement of Best Practice
- To provide guidance for requesting and maintaining SSL/TLS certificates
- These guidelines are for use when requesting an InCommon/Sectigo certificate and may not be applicable to certificates from other sources
Contact
- Information Security Office
Environment
- 12587: Certificate Services
Certificate Characteristics
Key generation
The SSL/TLS protocol uses a pair of keys to authenticate identities and encrypt information sent over the Internet. One of these (the public key) is intended for wide distribution, and the other (the private key) should be kept as securely as possible. These keys are created together when you generate a certificate signing request (CSR).
- Length: 2048 RSA key at minimum
- Expiration: 1 year is the maximum period of time for any certificate request
Renew a certificate
The InCommon Certificate Service doesn't offer certificate renewal; you must instead request a new certificate using the Certificate Manager mentioned above.
If you've enrolled into certificate automation via ACME and certbot, then cerbot will manage the automatic renewal of your certificate. This service is managed by EO and the Windows team.
When to use a wildcard certificate
Wildcard certificates, when compromised by attackers, have the potential to be far more damaging to Miami than standard certificates since they could be used to impersonate any FQDN in the domain of the wildcard, rather than just specific FQDNs to which standard certificates are issued. Placing copies of the wildcard certificates and their accompanying keypairs on multiple machines also increases the attack surface of the certificates. For this reason, wildcard certs:
- Must be recreated with new keypairs, not renewed
- May only be used when more than 100 FQDNs are involved. (If fewer than 100 FQDNs are needed, request a SAN SSL certificate instead)
- Exceptions to these restrictions require approval by the University Information Security Office, who will ask the request the following:
- What host-level measures exist on the servers containing the private key for the wildcard certificate?
- What network-level measures protect these servers?
- Where else will the private key be stored?
- What people will have access to the private key?
- What is your response procedure in case the private key is compromised?
- How many FQDNs do you need the certificate to be valid for? What are they?
- How many servers do you plan on putting the wildcard certificate on?
- Where are these servers physically located?
- If you have been approved to use a wildcard certificate, the Information Security Office recommends the following best practices:
- Develop a response procedure to respond to a compromise of the private key
- Deploy the private key only where needed (e.g. not to every server you run, only those that need it, etc)
- Limit access to the certificate to only those staff who need it
When to use a SAN certificate
SAN certificates (multi-domain certificates) are useful when different domains need to be trusted by the same certificate. Remember, a wildcard is only able to provide access to any DNS name in a single level of a single subdomain. SAN certificates support up to 100 fully qualified domain names (FQDNs) or host names.
Domain validated vs. organization validated SSL certificates
DV certs offer the lowest, most basic level of validation. The entity requesting the certificate must prove their ownership and control over the domain/ URL to be secured by SSL.
OV certs offer a higher level of validation. The entity requesting the certificate must prove their control over the domain/ URL to be secured by the SSL and that their organization is a legitimate one. Since the entity must provide legitimate business information and the CA (Certificate Authority) scrutinizes the legitimacy of the organization,
Tips
- Generate your own private keys on a secure and trusted environment (preferably on the server where they will be deployed or a FIPS or Common Criteria compliant device)
- Never allow a CA (or anyone else) to generate private keys on your behalf
- Only give access to private keys as needed
- Renew certificates as often as practically possible (at least yearly is required), preferably using a freshly-generated private key each time. Automation tools like the ACME protocol are helpful for scheduling frequent certificate renewals