This is targeted to IT professionals that are responsible for maintaining (Web) server certificates for systems and software at Virginia Tech. This article covers a number of notable pain points and recommended best practices for interoperability that are intended to strike the optimal balance between security and usability.

Security Considerations

Key Algorithm Selection

While the RSA algorithm is by far the most popular asymmetric cryptography algorithm for most of the history of X.509 certificates, elliptic curve cryptography (ECC) algorithms MAY offer a better balance of security and efficiency. We offer the following simple advice: use ECC for Web servers whose clients are exclusively or predominantly browsers; use RSA for everything else. The rationale is that ECC provides equivalent security with shorter keys and as such tends to be more efficient. Given that ECC support is broadly supported in modern browsers, Web servers that are simply providing content to browser clients are an ideal candidate for ECC. On the other hand, Web servers that are provide services to non-browser clients such as a REST API host may encounter compatibility problems with clients that use PKI libraries that do not adequately support ECC. Servers that use protocols other than HTTP, e.g. LDAP, are similarly at risk of client support problems with ECC; RSA is best for those cases.

There has been much discussion about the security of “base curves” for use with ECC algorithms. While there are some fervent viewpoints on the matter, we simply recommend using a well-supported NIST-approved curve such as prime256v1. Note that the choice of base curve MAY have a dramatic impact on interoperability so choose wisely.

Recommended Key Length

The recommended acceptable minimum key length is a function of key algorithm and is based on current NIST recommendations:

• RSA: 3072 bits
• EC: 256 bits

While the above are minimum acceptable values, we believe they are sufficient for most use cases. Note that we are aware that AWS does not support ECC keys of length greater than 224 bits as of this writing (Q2 2023), thus platform and software support as well as general interoperability considerations MUST be weighed when choosing algorithm parameters. Said another way security and usability must always be considered together to strike a proper balance.

Key Management Practices

The private key that corresponds to a public certificate should be treated with the same care and discretion as a password credential. If the private key is stored in a file on the filesystem, which is common, the key should at a minimum be readable only by users of processes that require access to read the key. Ideally the key would be stored in an encrypted container such as a PKCS#12 file where the password to decrypt the file is provided at process startup time or obtained by another secure facility such as Vault. In cloud environments, key material may be securely injected into runtime environments via platform-specific facilities.

Usability Considerations

Certificate Chains

All TLS peers, whether client or server, SHOULD present a certificate chain that consists of the end-entity (i.e. server) certificate followed by every issuing CA certificate up to but not including the root CA certificate. For example, given an InCommon server certificate for party.vt.edu, a Web server should emit a certificate chain consisting of the following:

1. CN=party.vt.edu,OU=Some Org,O=Virginia Tech,dc=vt,dc=edu
2. CN=InCommon RSA Server CA 2,O=Internet2,C=US

Note that the root CA, CN=USERTrust RSA Certification Authority,O=The USERTRUST Network,L=Jersey City,ST=New Jersey, C=US, is not included in the certificate chain emitted by the server. The SSL Labs site verification tool provides a check for adherence to this best practice, so it SHOULD be used as a check on proper Web server certificate chain construction.

Configuring Certificate Trust

Given that the above recommendation is followed, certificate trust should be configured in terms of well-known root certificate authorities. These tend to change infrequently and therefore are the most stable trust anchors. Moreover, the USERTRUST CA is commonly included in platform CA bundles so in many cases simply using the platform-provided CA bundle should be sufficient for applications that need to make TLS connections to Virginia Tech services secured with InCommon server certificates.