I'm new to python as well as Let's Encrypt and wanted to understand what/how does one work with ACME protocol using a python script to request a new cert or renew an existing one. This is not going to run on a server. I understand the process of having to show ownership of your domain but I see that as a separate and manual step to update DNS with a TXT record.
Can someone please show me an example of a python script that by providing the domain name it will initial an SSL request? I have already created an account key but I am not familiar as to how to use in in the script to make an SSL request.
with Let's Encrypt's initial directory endpoint being https://acme-v02.api.letsencrypt.org/directory, which is where clients start from. (This isn't necessarily at all straightforward for people implementing this for the first time, so @jvanasco's reference to a sample implementation is probably more helpful—but this is the documentation when you're ready for it or if you want to compare it to the implementation!)
Thank you both @schoen@jvanasco. I have already reviewed that article but noticed that in step 3, it refers to running it on a server. My goal is to write a tool that would only use the API to make a request for a new cert or renew a cert without having a server to install it on.
The idea is to make the API call to request a cert (new or renew) for a domain (and or additional domains) which would then generate a TXT record that I can then create to validate the domain/s. That would generate the necessary files (in the different formats) which I then download and use to import the certificate into AWS.
We have a similar process we are using with GlobalSign, but I am pretty sure those are different providers and the process is not entirely the same, so I can't use that as an example. I am new to this concept of SSL cert requests via API, therefore I assume description above is not accurate. I would like to learn more about it and eventually write a tool (or re-use one that already exists and modify to my needs) that does approximately what I described.
I keep reading about "account key" though I don't know where or how to generate or get one or how to use it. Reading more about it I found this paragraph.
When it comes to Let's Encrypt, you need an RSA private key to associate with your Let's Encrypt account. This account key is used for communication with the Let's Encrypt ACME (Automated Certificate Management Environment) server, which is responsible for issuing and managing your SSL/TLS certificates.
To generate a new Let's Encrypt account key, you can use the openssl genrsa command or any other method that generates a compatible RSA private key. The generated account key is then used in conjunction with the Let's Encrypt ACME API to authenticate and authorize certificate requests, renewals, and other account-related actions.
Once you have the account key generated, you can use it within the script or an ACME client library to interact with the Let's Encrypt ACME API and manage your certificates, including renewal, revocation, or obtaining new certificates.
In summary, running the openssl genrsa command is a step in the process of generating an RSA private key, which is a prerequisite for interacting with Let's Encrypt for certificate management using ACME clients or custom scripts.
You generate a key and sign up for the API with it. Typically you’d be using a library and it’ll take care of it for you.
There’s an example here which uses HTTP challenges, which you should be able to adapt to using DNS instead.
To break it down a bit more:
This section creates a private key you'll use to authenticate to the API, and then registers for an account:
Then we create an "order", requesting a cert:
Next, this is where things change a bit for DNS. This code starts an HTTP server and finalizes the order. For DNS, you'll want to put an entry in your DNS server instead, but then you'll do the same thing and tell the CA to check DNS, then "finalize" the order, which will actually issue the certificate.
@mcpherrinm Your example is using CertBot. CertBot (as far as I understand) must run on a server.
My goal is to use a tool that does not run on a server but is just a script that make requests for a new or renew a certificate. Unfortunately, I don't have any certificates with Let's Encrypt so I can't test anything.
I have a domain "example.com" and I own it. I have it registered in AWS (Route53) and I control the DNS. I now want to host a new app and it will be running on EKS behind an ALB. I configure the ALB to point to my domain "app.example.com" and I want to generate a new certificate for this domain and configure my ALB to use that certificate.
Normally, I would send an email to a team and tell them I need a new certificate for this domain, they then provide with a set of files (.csr, .pem, .oid, etc) I then use those files to import the certificate into AWS and I'm all set.
I now want to, instead of asking that team to generate those files for me, to generate them myself by using a tool that I would provide the domain/s and it will respond with the TXT records to validate the domain which then generate the files that I can then download (most likely from an S3 bucket) and import the cert into AWS.
Sorry, for the long story, but I just need to make sure my scenario is clear as I am getting suggestions that I'm not sure apply 100% to what I'm trying to achieve.
No. Especially with the DNS Challenge this is not required. You still have to somehow get the certs from where you run it to where you want to use it. But, this would be true of any ACME client - even one you write.
You can also run Certbot in manual mode from any machine using HTTP or DNS Challenge. But, manual modes cannot have automated renewals because, well, they need manual intervention. And, the HTTP Challenge requires you to be able to place file(s) in a webserver folder (using ftp, ssh, or whatever).
Oh, and is there a reason you don't use AWS ACM certs in the ALB?
Don't have time to walk through your entire workflow. But, you could just run Certbot using the Route53 plug-in and get a cert using any machine you like. Just as if you sent a request to a team and got files back. You then deploy those cert files (cert, chain, private key).
The Certbot Route53 plug-in doesn't cope with complex IAM/Zone setups in Route53. Personally I'd rather tweak a bash script like acme.sh if all you need to do is customized Route53 stuff.
The most common use puts certbot on the same server that is running a web server; And the certificate will be used to secure some web site(s).
But, that is NOT the only use for certbot.
It can even be run on Windows 10 [clearly NOT a server]; And completely out-of-band [without any web service].
That said, there are also many other ACME clients out there.
Most of which can do some form of manual DNS challenge authentication.
But you should really consider the amount of time/effort such a path will require.
The end-game is automation.
If you can automate the renewals [regardless of the path/client chosen], you can win the "cert game".
Otherwise, you will be a slave to that process every 90 days [or less] for as long as you need certs.
Thank you all for chiming in. I appreciate the suggestions.
I think my manager is looking for us to build our own full blown tool to manage the request/renewal of certificates (same as what we do for GlobalSign). I know it's a bit undertaking and why now use already existing tools, but that's what I am gathering from conversations.
That aside, if I'm still looking to even being able to make an API call, I understand I need an access key or an API Key. While I have my own Let's Encrypt account (this one...) I do not see anything about keys anywhere in the portal. Maybe that's the first thing I need to get my hands on to even start anything?
The account you're talking about now is not the same as an account for getting certificates. This is just a forum with its own software and also its own account. It's not connected to the ACME server of the Let's Encrypt CA.
Hearing this I think you might want to read more about the basics of the ACME protocol. E.g. see:
Note that the terminology can be a bit inconsistent. So in addition to the community forum account being totally separate from the ACME account, the key you're talking about is sometimes also called an "ACME account" or "account key". Some people have favored terms like "API key" because it's not exactly an account that you can, for example, log into a web site using—it is only ever used for making API calls, and for Let's Encrypt to send some e-mail notifications if you've associated an e-mail address with it.