This article is primarily intended for software publishers, IT service providers and IT research and development teams. Whether you deliver your product to your customers, provide specific applications or install applications in-house, you need to ensure that they run in a secure environment and communicate using encrypted protocols such as HTTPS.
To achieve this, the target organization must manage the life cycle of its digital certificates, which are the cornerstone of encrypted protocols. Even after digital certificates have been deployed for all incoming and outgoing communications, your information system is still exposed to a number of risks. This article focuses mainly on two such risks:
- Quality of digital certificates: We will examine two topics that impact quality:
- Quality of technical characteristics (e.g. key generation algorithm, certificate signing algorithm, certificate use, etc.)
- Quality of trust-related characteristics (e.g. issuing certification authority, certification policy, generation procedures, etc.). These are the core components of your PKI.
- Lifetime: Each certificate has a specific lifetime. On reaching its validity end date, services that use it will become unavailable, to prevent you from using expired certificates. Using an expired certificate exposes the server or user to the risk of identity spoofing.
The first step towards covering these two risks must therefore be to write a compliance policy that defines appropriate quality requirements. Thereafter, measures must be taken to uphold the specified quality over time. For example, in 2005, all certificates had to be issued with a basic “sha1” hashing algorithm as standard. Today, the “sha1” algorithm is obsolete and vulnerable. Compliance criteria evolve quickly. As a result, a continuous quality process must be implemented, based on a Plan-Do-Check-Act (PDCA) approach, for example.
As well as addressing the vulnerability of algorithms and the obsolescence of issuance criteria (even for renewals), it is important to uphold compliance over time.
For example, you might initially generate your certificate in the right conditions. When it is renewed a year later, however, you have no guarantee that your operational personnel are still complying with the criteria originally established. The team might not follow the specified renewal procedures. The result would be a non-compliant certificate installed on your platform.
How can we manage this issue?
In this article, we describe how to implement a continuous integration and deployment factory based on BerryCert, enabling you to deliver secure, policy-compliant applications to your customers.
BerryCert will also provide the traceability and validation workflow you need in order to enforce your information system security policies, as well as more demanding standards such as ISO 27001 or PCI-DSS.
This article continues in the form of a guided tutorial, using specimen configurations of the various assets. For greater clarity, we have made the following choices:
- Rather than using a DevOps orchestration tool, we have described a step-by-step process suitable for any computer. (This process could easily be adapted for tools such as Jenkins or GitLabCI.)
- We have chosen Docker for the delivery and packaging format. You could also conduct the process using other formats, such as VM images, for example.
- We are using Apache HTTPD as our target application. The aim is to show the workflow for an application that supports the https communication protocol.
We are also assuming that you have access to a BerryCert account configured with:
- Compliance policy
- Access to your PKI
- Compliance policy
- Issuance policy
- An ID for your agent
For more information on configuring BerryCert, refer to our FAQ (TODO).
Integration at the build stage
The purpose of this step is to build secure images with the https protocol by default, using certificates that are compliant by default. We will be using a multi-stage build technique where we create a build image, execute the build in it, retrieve the result and copy it to the final (production) image. We will create our own certification generation ‘stage’ and copy our certificates to the final image.
Build phase integration strategy
The following steps must be performed in your Dockerfile:
- Inherit your base image: In the base image, we are assuming that you have already enabled https mode, with self-signed certificates, for example. This base image is available here: repo.com/apache:2.4-insecure-alpine
- Download the BerryCert agent: The BerryCert agent is a utility that lets you manage a target application. It can be run either directly, by BerryCert, or manually, in CLI Authentication is required in order to download it. Please request credentials from the Digitalberry support team, and then insert them in the following command, after the curl command’s -u argument.
Note: The agent is distributed in various formats for different target systems (Windows 32 & 64 bits, Linux 32 & 64 bits, and Alpine 32 & 64 bits). Download the appropriate distribution for your base image.
- Run the BerryCert agent: When run with the –auto parameter, the BerryCert agent will perform the following operations:
- Scan the existing certificates and send them to BerryCert (for traceability reasons)
- Generate a new key pair in the build image
- Generate a Certificate Signing Request (CSR) based on the new key pair
- Send the CSR to BerryCert
- Wait (in a polling loop) until the CSR is signed
- Deploy the newly issued certificate
This command must be added to your Dockerfile
The BerryCert agent arguments are as follows:
|Auto||username of the agent created on the BerryCert side|
|Server||ID of the issuance policy that you created in your BerryCert organization|
|Usage-id||used to retrieve the file paths of certificates and private keys generated by BerryCert and store them in a temporary file|
|Username||URL of the relevant BerryCert server|
|Password||password of the agent created on the BerryCert side|
|Updated-files||instructs the agent to manage the target application from end to end (including scanning, renewal and deployment)|
- Copy the generated directory to the base image:
- Copy the generated assets into a temporary directory (copying the entire tree, not just the files)
- Copy assets from the first image (–from=0) to the second
- Enable SSH: This step will enable subsequent connections by BerryCert for the purpose of managing the life cycle of issued certificates
For enhanced security, we recommend adding an entrypoint.sh that correctly manages the SSH service (ssh key, etc.). For now, we are enabling SSH to allow BerryCert to connect during phase 2 of the process. SSH protocol security is outside the scope of this article.
- Generate the secure image: At this point, you are ready to build your image by entering this command on your terminal:
1docker build . -t local/apache:2.4-secure-alpine
Your image is now available locally; it is secure and you can push it to your production repository.
Several multi-stage building strategies exist; we have chosen this one for our example as it does not require a complete DevOps chain
- Deliver Docker images with compliant certificates from the outset
- No need to install complex cryptography tools for your production images, particularly as they are not useful during real-time execution.
- No need to write an additional procedure or add more automation tools in order to install compliant certificates for your https. BerryCert manages the process for you.
- You can create jobs with parameters in order to build development images (e.g. Snapshot or RC) from the development PKI, and Production images from the Production PKI. This means that developers can work in an environment similar to the production environment during the development phase. You can edit the agent’s –usage-id parameter in order to issue certificates with a particular policy.
- Renewals are not yet managed at this stage
- In some information systems, you may not have access to the production PKI at the ‘build’ stage. You can use the process to manage development images very similar to the production versions.
- At this stage, you may not yet have the relevant deployment information (e.g. Server name, SAN, etc.)
We are going to describe a supplemental strategy that lets you manage your server instance during the run phase in production.
Integration after deployment
In the previous step, we explained how to build a Docker image with compliant certificates. Now, we are going to deploy this image and manage the certificates for the instance via the BerryCert utility. We have not described the deployment process as part of this step: you may deploy the image however you see fit (e.g. via an SSH connection, Ansible, etc.)
Deployment phase integration strategy
When you have deployed your image, the server must be registered with BerryCert, using REST APIs
- Authentication: You must use your credentials (as your organization’s administrator) to obtain a JWT token. The necessary curl command is as follows:
|URL||URL of the BerryCert server, to which we add the URI of the authentication API||https://berrycert.digitalberry.fr/api/v1/auth/|
|Username||Your BerryCert username (administrator)||email@example.com|
|Password||Your BerryCert password (administrator)||password|
Response from the server:
Your JWT token is in the id_token field.
- Add the server’s SSH credentials: The necessary curl command is as follows:
|content.password||Password of the user authorizing SSH access to the server. Refer to the API documentation for more details.||password|
|content.auth_type||Desired protocol subtype. Refer to the API documentation for more details. We will be using the SSH_PASSWORD protocol for our tutorial||SSH_PASSWORD|
|Authorization header||The header must contain your JWT token (obtained during the authentication step). The token is prefixed by the “Bearer “ string||Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMiwid XNlcm5hbWUiOiJoYW1kaS56cmFyaUBnbWFpbC5jb20iLCJleHA iOjE2MjAxNjEzOTgsImVtYWlsIjoiaGFtZGkuenJhcmlAZ21haWw uY29tIn0.rVrdsLJfGhqLq8JDys_cUeEjey0A-uR_YpIdDR7oaw|
Response from the server:
Get the ID of the created object (in the id field); we will be using it in the next step
- Declare the server to BerryCert The necessary curl command is as follows:
|URL||URL of the BerryCert server, to which we add the URI of the server management API||https://berrycert.digitalberry.fr/api/v1/hosts/|
|Le header Authorization||The header must contain your JWT token (obtained during the authentication step). The token is prefixed by the “Bearer “ string||Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMiwid XNlcm5hbWUiOiJoYW1kaS56cmFyaUBnbWFpbC5jb20iLCJleHA iOjE2MjAxNjEzOTgsImVtYWlsIjoiaGFtZGkuenJhcmlAZ21haWw uY29tIn0.rVrdsLJfGhqLq8JDys_cUeEjey0A-uR_YpIdDR7oaw|
|Name||Free string indicating the server name. This string simply identifies the server in the BerryCert interface||My Server|
|Tenant||Name of your BerryCert organization||mu_org1|
|Protocole||Desired protocol. Refer to the API documentation for more details. We will be using the SSH protocol for our tutorial||SSH|
|fqdn||Desired protocol subtype. Refer to the API documentation for more details. We will be using the SSH_PASSWORD protocol for our tutorial||server1.localdomain.infra|
|port||Port used for SSH access to the server.||22|
|credential_id||ID obtained while creating the user credentials.||67|
Response from the server:
Server management is asynchronous. BerryCert will attempt to connect a few minutes after receiving the query.
Now that your server is being managed by the BerryCert utility, you will see it in the server list. The workflow that you configured for BerryCert will be applied. If automatic management is enabled, your server’s certificates will be renewed and deployed according to your compliance policy and their validity dates. For more information on configuring these settings, refer to our FAQ (TODO) here.
This phase supplements the initial build phase by adding your server to your BerryCert workflow. BerryCert will manage it in future. A fully-automated workflow might look like this:
- Run scheduled, routine scans on all registered servers
- Perform scheduled, periodic renewals of certificates that are:
- not compliant with the specified compliance policy
- soon to expire (within 15 days)
- Periodically and continuously deploy all renewed certificates
This detailed article explains, step-by-step, how to integrate the BerryCert utility in order to deliver secure Docker images and continue to manage them post-deployment. Although we used Apache https and docker for our example, our BerryCert agent and APIs allow the approach to be adapted for all types of infrastructures, allowing easy integration. Please contact us if you have any questions. We will be happy to help you integrate BerryCert into your infrastructure.