Secure configuration management tasks with a certificate authority

Certificate basics

To operate, networks exchange packets of data between various devices or nodes. Network security focuses on validation -- ensuring that the sending and receiving nodes are the intended physical devices. This validation process is called authentication. Users are typically authenticated to servers on the network through credentials, such as usernames and passwords.

But user authentication is only part of the process. Servers must often authenticate themselves to the client systems that use their resources, while many client systems must also provide adequate authentication to the servers or other client systems that communicate over the network. Without this authentication, there is no way to determine whether the particular server or client system is trusted and legitimate.

The primary means of system-to-system authentication in modern networks is the digital certificate -- sometimes just referred to as a certificate. This is a special file that contains information, including the identity and public encryption key of an entity such as a person, business or system. A certificate authority (CA) then checks and validates that information. If the CA verifies the entity's identity and public encryption key, the information is then encrypted with the CA's private key to create a digitally signed certificate.

The certificate authority server sends a signed certificate to endpoints to use as the basis for Secure Sockets Layer (SSL) encryption between the server and the client, with confidence that the certificate represents the intended node. The key is typically used to create a temporary and disposable symmetric key that enables data encryption throughout the entire session. Even if the data is intercepted, it cannot be read or decrypted.

Configuration management platforms often integrate with a CA to maintain and exchange certificates with the client systems they manage. Thus, those client systems use certificates to ensure they exchange configuration changes or management information with an authentic management server.

CA tasks in systems management

Tools commonly involved in systems configuration and management -- again, such as Puppet, Ansible and Chef -- will include a certificate authority server as part of their functionality. For example, Puppet uses HTTPS for network communication, as well as X.509-compliant certificates. The highly automated certificate authority server enables the platform to manage its own certificates and maintain secure network communication with the devices under management.

The actual number of tasks that an IT administrator can perform with a CA server is limited, but those tasks are vital to configure and secure the management environment.

First, a CA server can regenerate certificates if a certificate authority becomes damaged or compromised. Administrators can typically log into the tool's console and run a straightforward command string to initiate the new certificates. A Puppet administrator, for example, can log into the master CA server as root and run a Puppet Infrastructure command line such as:

puppet infrastructure run regenerate_agent_certificate agent=<AGENT_HOSTNAME> caserver=<CA_SERVER_HOSTNAME>

By comparison, Ansible's openssl_certificate module uses a series of commands that delineate paths to critical locations. As an example, the sequence to generate an OpenSSL certificate signed with the CA might look like:

- name: Generate a CA-signed OpenSSL certificate
  openssl_certificate:
    path: <path where the generated certificate should be created or is located>
    csr_path: <path to the Certificate Signing Request that generates the certificate>
    ownca_path: <path to the CA>
    ownca_privatekey_path: <path to the CA private key>
    provider: ownca (the proper option to note what is generating the certificate)

Second, systems management tools enable administrators to set up an independent, third-party certificate authority, such as Verisign. This can be helpful when the enterprise wants to use a public CA, rather than the tool's own CA. The actual process to configure an independent CA varies between tools and involves numerous steps, so follow the tool's documentation.

For Puppet Enterprise, the process typically involves copying sensitive data -- including the certificate authority, certificate request and private key information -- to wherever the admin installs the CA master. Install Puppet Enterprise, adding the signing_ca parameter to the pe.conf file. The signing_ca parameter must include key value pairs for bundle, crl_chain and private_key. These details provide the installation with path information for important certificate authority data. After installation, create a certificate, using OpenSSL tools installed with Puppet, to check that the CA works.

Third, administrators can create a custom or self-signed certificate. A self-signed SSL certificate is signed by the same entity that it is intended to identify, and with its own private key. Some organizations opt to self-sign if internal CA safeguards are in place. However, self-signing is generally discouraged because the certificates are not trusted by other applications or OSes, might use weak hash or cipher technologies, and cannot be used by the broader public key infrastructure (PKI).

As an example, Ansible's openssl_certificate module might use the following sequence to generate an OpenSSL certificate self-signed with the CA:

- name: Self-sign a CSR and create a certificate
  openssl_certificate:
    path: <path where the generated certificate should be created or is located)>
    privatekey_path: <path to the location of the private key>
    privatekey_passphrase: <the private key password>
    csr_path: <path to the Certificate Signing Request that generates the certificate>
    provider: selfsigned (the proper option to note what is generating the certificate)

Fourth, administrators can typically implement configuration changes to the CA host master. As an example, an admin can use the Chef Infra Server to tune the Nginx service and optimize the use of SSL certificates. This can include stipulating specific values for the SSL certificate used to encrypt communication over HTTPS; selecting the preferred ciphers for encryption, such as AES256 with ECDHE; enabling or disabling Transport Layer Security (TLS); and setting the preferred protocols, including TLS 1.0, TLS 1.1, and TLS 1.2.

Secure the systems management CAs

The certificate authority must be a trusted resource in the enterprise. Although the scope of a security breach is limited in a systems management environment, the implications for sensitive data loss and business disruption are serious. A compromised CA means compromised security, as there is no way to ensure the authenticity of digital certificates. Given the importance of certificates and security in systems management environments, make it a top priority to set up and protect the certificate authority server for Puppet, Ansible, Chef and similar tools. Include any access to CA server deployment, setup and configuration in security alerts and auditing processes to preserve CA integrity.