Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
GSoC 2017: Support for "Let's Encrypt" ACME protocol #1959
Ejabberd support for "Let's Encrypt" ACME protocol
This is the final pull request for this: https://summerofcode.withgoogle.com/projects/#5214033996152832 GSoC 2017 project.
This project implements support for the "Let's Encrypt" ACME protocol. It is a protocol that allows for certificates to be acquired in an easy, automated way, without any human intervention. So the main functionality of the implementation is acquiring and managing the aforementioned certificates. Below I will describe in detail all the functionality that this project implements.
There are two typical scenarios that the client has to support:
Despite being described thoroughly in the latest ACME draft: https://tools.ietf.org/html/draft-ietf-acme-acme-07 I will try to give a brief overview of those two scenarios.
In order to acquire a certificate for a domain, a client has to:
In order to revoke a certificate, the client has to just send a revocation request.
Knowing the above I decided to implement 4 commands that the user can use in order to acquire, manage and inspect certificates for their domains.
This is the most essential command that the client uses. It acquires a certificate for all hosts specified in the configuration file or for a specific set of hosts that the user requests. This command basically follows all the steps of the first scenario above.
The renew_certificate command renews all managed certificates that are 30 days (or closer) to expiration. This command should be scheduled for execution every day or so, in order to make sure that all certificates are up to date.
This command pretty prints all managed certificates in plain or verbose mode. Specifically, in plain mode, it prints their domain, SANS, expiration date and path. In verbose it prints the domain, SANs, expiration date and certificate/key.
This command revokes a managed certificate for a specified domain. This command should be used when there exists serious concern that a certificate/key has been compromised.
The implementation is split in 3 modules that are clearly separated from each other.
This module deals with solving the challenges that the CA issues. The only challenge type that is currently supported is "http-01". If more challenge types are to be supported they should be included in this module.
This module contains functions that implement all necessary http requests to the ACME CA. Its purpose is to facilitate the ACME client implementation by separating the handling/validating/parsing of all the requests from the application logic.
This is the main module of the project. It contains implementations of all the aforementioned commands and the certificate management. It only contains application logic and calls functions from ejabberd_acme_comm in order to communicate with the CA.
An example scenario would be to first execute
And then have a script be scheduled to run the following command every day or so
Known Issues / Things left to do
The implementation offers basic support of the ACME protocol. However it is not complete and has some known issues. I will try to include all of the issues and future tasks here.
The main issue is that I haven't tested the client on the real "Let's Encrypt" ACME CA because I don't have control of any domain. That is why I have only tested the implementation with a local CA by redirecting all domains to localhost. Because of that I am not sure whether everything works correctly on the real CA.
Any feedback on this project is greatly appreciated.
So to get this straight, I will add a
Yes. But make sure you put the path in the head of the list.
Merged with some fixes.
Should I store the intermediate certificate in the same pem file with the acquired certificates? The intermediate and root certificates can be found here Let's Encrypt Certificates. I suppose that we need the X3 IdenTrust cross-signed.
There are two ways to call
I have never encountered this error, I have to check it.
What exactly do you mean with this? Can you elaborate?
@zinid There is no need to hardcode them, we could get the intermediate certifcate everytime we need it from https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt .
@zinid There is a problem, when I save the end certificate, the issuer certificate, and the private key for the end certificate in a pem file and try to add it,
This problem appeared now that I am trying to include the issuer certificate in the pem file.
I got the PEM file, I'm checking.
acme: ca_url: "https://acme-staging.api.letsencrypt.org"
I have an error:
It is this branch https://github.com/angelhof/ejabberd/tree/acme_keep_issuer_cert
This is fixed by this: