Public Key Infrastructure

TNSR supports Public Key Infrastructure (PKI) entries for X.509 certificates and SSH keys for various uses by the router and supporting software. PKI uses a pair of keys to encrypt and authenticate data, one public and one private. The private key is known only to its owner, and the public key can be known by anyone.

PKI works in an asymmetric fashion. A message is encrypted using the public key, and can only be decrypted by the private key. The private key can also be used to digitally sign a message to prove it originated from the key holder, and this signature can be validated using the public key. Combined with certificates, this provides a means to identify an entity and encrypt communications.

For X.509, A Certificate Authority (CA) independently verifies the identity of the entity making a request for a certificate, and then signs a request, yielding a certificate. This certificate can then be validated against the certificate of the CA itself by anyone who has access to that CA certificate. In some cases, this CA may be an intermediate, meaning it is also signed by another CA above it. All together, this creates a chain of trust starting with the root CA all the way down to individual certificates. So as long as the CA is trustworthy, any certificate it has signed can be considered trustworthy.

For SSH keys, the private key is held locally on a client while that client’s corresponding public key is added to a list of authorized keys on a server to allow that client to access the server. These keys are much more secure than using passwords for authorization, and since only the public keys are exchanged, allowing access for new clients is secure and has no concerns about coordinating a private means of exchanging new credentials.

Due to their size and private nature, certificates and keys are stored on the filesystem and not in the XML configuration. PKI files are stored under the following locations:

  • Certificate Authorities: /etc/pki/tls/tnsr/CA/

  • Certificates, Signing Requests, and PKCS#12 Archives: /etc/pki/tls/tnsr/certs/

  • Private Keys: /etc/pki/tls/tnsr/private/

  • SSH Keys: /etc/pki/tls/tnsr/ssh/

X.509 key, CSR, certificate, and PKCS#12 entries associated with each other must all have the same name. SSH public and private keys for the same entry must use the same name.

The process for creating a new X.509 certificate is as follows:

  • Create keys for name.

  • Create a certificate signing request for name with the attributes to use for the certificate.

  • Submit the CSR to a CA, which will sign the CSR and return a certificate.

  • Enter or import the certificate contents for name into TNSR.

The process for creating a new SSH key is as follows:

  • Create a new set of keys with ssh-keygen

  • For keys TNSR will use to access remote servers, import the private and public key.

  • For keys TNSR will use to authorize remote clients, import the public key only.