Automate SSL cert generation and renewal using REST API


Let me eexplain what we are doing first. We support whitelabelling of domains to our software. That means, you can point your domain( to our servers and we will serve that securely using https. So, we have to generate and renew ssl certs for many domains. Currently the number is around 5k certs.

We are using lua-resty-auto-ssl. But we are running into certain issues with it. First thing is, we are storing the certs in redis(earlier we stored on disk). But we want to be able to store it on MySQL. The issues are mostly related to rate limiting and the retry mechanisms if cert generation/renewal fails.

What I want to do is create a nodejs application(call it cert-manager) and expose some endpoints using which I can handle the generation and renewal of the certificates. For example,

If I want to create a cert for a domain, says, I should be able to do it by making a REST API call to my cert-manager application endpoint, like /certs/generation/ And if I want to renew a cert I should be able to do using, /certs/renewal/

And I want to be able to store these certs in MySQL.

Also, I have successfully used greenlock-express with greenlock-store-sequelize to generate certs and store it to MySQL.

But with these packages, I am only able to do it on the fly and in our current system we are doing exactly that but with lua and redis. I want to do it on demand(like above I said using REST APIs). Is that even possible? If yes, can someone please show me the way.

1 Like

Hi @luvpreetsingh,

A tool developed by a community member here that might be relevant to your use case is

It's especially meant for large hosts that are hosting large numbers of domains, to try to address scaling issues.

Other than this, I believe that the things you want to do are achievable, but would probably require some custom development and integration work, because they might not be provided out-of-the-box by existing Let's Encrypt integration tools.

Another thing you might want to look at is the Caddy server

although it might be more integrated and have less overall policy control than you want. Caddy has very convenient auto-certificate features and can also be used as a reverse proxy, so you don't necessarily have to replace your existing infrastructure with Caddy in order to use it for TLS termination.


You can also look at self-hosted and cloud based secret stores, so you fetch your certificate then store it in a vault for later use by your applications.

Hashicorp Vault is one of the best known self hosted options and supports a wide range of backend storage options, cloud options include Azure Key Vault, AWS Secrets Manager, Google Secrets Manager and others.

In all cases you usually need to store the certificate (for the end-entity), the full certificate chain and the private key, so that the application calling the rest API can download all those things as well.

It sounds like you already have the required software development expertise in-house that could build such an API/storage layer in a short period of time. I wonder if your question is more around the renewal process? If so, your certificate management layer would need to perform the renewal and push certificates to the storage layer, then applications would need to regularly fetch the latest cert from the API and restart (if required).

1 Like

Thank you for the quick helpful replies.

I didn't know about peter_sslers and the caddy server.

peter_sslers looks good but the only(major issue) is the lack of automatic renewals and they are working on it.

I will try Caddy and get back to you guys on that.

This following part is unrelated to letsencrypt but my main difficulty with custom development and integration is that the greenlock-express docs are not much helpful. Also, JS isn't my strength so there's that. I guess it should be possible using python too, right?

Here in this article, it says that, There are two steps to this process. First, the agent proves to the CA that the web server controls a domain. Then, the agent can request, renew, and revoke certificates for that domain.

So does that mean the certificate can only be issued if we are requesting from a web server?

Why I am asking this is because if a web server is required then what I want is not possible.

This would be the ideal flow. We are looking to completely decouple the cert generation and renewal from the web server.

If you want your certificate generation decoupled from the web server, that's definitely possible but requires your certificate management system to be able to update your DNS server programatically to fulfill the DNS-01 challenges. That is, the agent proves to the CA that the agent has control over the domain (through updating DNS), and doesn't need to directly interact with the web server (though of course at some point the web server will need to get the certificate and private key from the certificate manager somehow).


Hmm, wouldn't that become an issue as we are providing White-label services? The client domain is actually not in our control.

Currently, we just tell the clients to add a CNAME record to our servers. We then use HTTP01 challenge and that works. For example, point to our.service.domain using CNAME.

But I don't think the DNS-01 challenge will work because we will then need control over their domains.

You'd just need your clients to give you a CNAME for the _acme-challenge. subdomain as well. That is, they'd set up a CNAME for to you as they do now, as well as to point to whatever DNS server you control (not necessarily on the same domain/server as the first one, perhaps this one using something like acme-dns).

Or, you could use HTTP-01 challenges instead, you'd just need your main web server to either support an API for handling the challenges that your central server talked to, or you could have the main web server redirect all /.well-known/acme-challenge requests to your central certificate server. Redirections are followed when checking challenges.

Be sure to check out the documentation on the challenge types if you haven't already.


I was able to do it. python client acme-tiny was the major inspiration. Used Flask and Flask-sqlalchemy to do the database work. Thank you very much everyone.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.