This is a continuation in a series of articles on Multitenant Applications. The previous articles talked about configuration management and this article talks about rotation of certificates. 

Multitenant solutions behave as infrastructure providers to tenants. This includes managing and maintaining secrets such as service accounts and certificates. The solution does not need to perform these duties itself and can delegate to external key management solutions for storing and rotating these secrets.  

While service accounts continue to be different from user accounts where the former represents applications and the latter represents users, the solution can register, persist, and rotate service accounts while delegating the same for user accounts to identity providers. User accounts are managed directly in the Active Directory and the solution does not interpret users; it validates assertions. Each request must assert an identity to the solution. The solution honors requests and every action is specified with the help of an API request at some level. Each request is unique, distinct, and self-contained for authentication and authorization purposes. Identity might merely an assertion in these requests.

 Service accounts are meant for interactions between tenants and their resources. A service account should never be mixed with user account otherwise they suffer many drawbacks. It should only be authorized with role-based access control otherwise any other scheme will encounter numerous items to audit. It should never be leaked, otherwise it can be abused indefinitely. This last item requires a rotation of service accounts so that the misuse of a service account is limited to its discovery an issue with the new account. The persistence of service accounts and their usage as a secret makes it valuable to an autonomous secret management system that can keep track of secrets and rotate them as necessary. The external key manager that manages keys and certificates was built for a similar purpose where the secret was a key certificate. That system can work well for a multitenant solution since it poses no restrictions on what these secrets are for.

The automation of periodic and on-demand rotation improves security and convenience for all solution provider usages. Service accounts can be backed by certificates, but the latter can be used for a wide variety of other purposes.

Certificates can be from different issuers. ACME issuer supports certificates from its server. CA supports issuing certificates using a signing key pair. Vault supports issuing certificates using a common vault. Self-signed certificates are issued privately. Venafi certificates supports issuing certificate from a cloud or a platform instance.

Although the solution manages the secrets, a consolidator can help with specific secret types. The libraries for this such as for certificate management are quite popular and well documented.   The use of libraries also brings down the code in the application to manage these specific types of secrets. The external dependencies for generating secrets are like any other dependency in the application code so these can be registered and maintained in one registry or container.

A self-signed certificate is one that is signed with its own private key. Generating a private key and public key is trivial for tools like openssl with the “–t rsa” command line option. For now, let’s look at the steps for self-signing. First, we generate a public-private key pair. Then we create the X509 certificate. Then we sign the certificate with its private key and providing the certificate to sign as well as the certificate with which to sign as the one we just created. 

Algorithms used for creating the keys are called digital signature algorithms. There are two kinds of encryption algorithms - RSA and ECDSA. In both cases, a message signed with the public key can only be opened with the help of the corresponding private key. RSA has historically been more popular with ECDSA gaining support only recently. They are usually compared in terms of bits to denote their security level. Bits is the number of steps taken before an attacker can compromise the security. A 2048-bit RSA public key has a security level of 112 bits. ECDSA needs only 224-bit sized public keys to provide the same security level which provides efficiency for storage. Signing and verification of the signature constitute the two most costly steps performed. The input size plays into this cost for embedded devices.  

The keystore and truststore can be one and the same if the connections are internal. In this case, the client and the server share the same key-certificate. On the other hand, mutual authentication is one where the server and the client present different certificates. In this sequence of message exchanges for mutual authentication between the server and the client, the server initiates the messages. First, the server sends hello message.  Next it sends the certificate, followed by a request to get the client’s certificate and lastly the server-side hello done message. The client responds first with its certificate. Then it sends the session key with the client key exchange message. Then it sends the certificate verify message and changes the cipher spec. Lastly it sends the client-side finished message. The server closes the mutual authentication with the cipher changed message and the server-side finished message.