Skip to content

How It Works

The objective of CASTLE ACME Email Server is to obtain a S/MIME certificate for email and document signing and make it possible automatically, without any human intervention. Our solution employs and implements the latests features of ACME protocol, which standardises the way of obtaining a certificate automatically.

Everything is possible by running an agent, which is in charge of validating the email account and requesting the certificate to the Certification Authority (CA). The overall process is performed in two steps. First, the agent requests an email validation. Once the CASTLE ACME Email Server has validated the email account, it requests to the CA a S/MIME certificate, specifically targeted to the validated email.

Probably you are familiarized with the automatic process implemented by Let’s Encrypt community. But instead of validating domains for a HTTPS certificate, here an email account is validated to prove the ownership of a particular email address.

Email Validation

In this process, the CASTLE ACME Email Server identifies a client by a public key. This public key is generated by the agent during the first time that it interacts with the server. The public key is stored at the server for future request, to identify the client and check the authenticity of client’s requests.

To prove the possession of an email address, the agent requests a validation to the CASTLE ACME Email Server. Then, the server responds with a challenge. This consists in replying the challenge via email with a particular response based on two tokens. These tokens are generated from the agent’s public key and a random unique bytes.

After the email with a token is sent to the email address, the client replies this email by attaching a unique response. This response is generated by using the token received by email and the token received during the process of request. To prove the possession of a particular email address, the client solves one of the following challenges:

  • Email Reply: the client replies the received email by attaching a unique ACME response, generated from tokens received in the email and via HTTPS.

The whole process is signed by agent’s public key and with a unique nonce.

After this process, the agent tells the server is ready to wait the results. In this moment, the server checks if the received response via email is correct, depending on the public key and the tokens. If the response is correct, the CASTLE ACME Email Server notifies the agent it has passed the challenge with success.

Certificate Issuance and Revocation

When the agent receives a positive acknowledge about the challenge result, it sends a PKCS10 Certificate Signing Request (CSR) to the server, which sends the CSR to the CA. The CSR is signed with its public key, as well as the whole request. If the CSR is correct and both signatures are also correct, the CA issues an S/MIME certificate based on the CSR and the public key within and returns it to the agent.

Finally, the agent constructs a PKCS12/PFX container with the private key, the public key and the certificate issued by the CA. This file is ready to be imported to email client’s key storage or OS key storage. Optionally, the PKCS12/PFX file is protected with a user-prompted passphrase.

The revocation works similarly. It generates a revocation request by attaching the certificate and sending it to the CASTLE ACME Email Server. The agent has two ways of signing a certificate:

  • Using the public key of the ACME account (the same as used in all the previous requests).
  • Using the public key of the certificate.

The latter case is specially useful when the user uninstalled the agent (and deleted the account private key). In this case, the user still has the choice of revoking the certificate by using its public key.