This may not be the correct location, but I wasn't sure Help was the right place, either.
I have not started using certbot, as I have a few questions.
First, I'll be generating a wildcard cert.Currently, it through GoDaddy.
I'll be on a RHEL server, currently 8.10.
My initial question is does this have to run on a dns server? The setup I have, I have a master and 2 slaves. The master is used for changes, which get propagated to the slaves. The slaves to the dns resolution work for my organizations external sites.
So, the second question is if I have to use a dns server, would I use the master, which doesn't have outside access, or 1 of the slaves?
I currently have a server, that I use to generate CSR, which is then normally sent to GoDaddy. Could this server be used instead of a dns server?
No, but to use it effectively, it has to be able to make automated updates to your DNS records. With non-user-hostile DNS hosts like Cloudflare, this is easy to do because they have a robust API they offer freely to their users.
A DNS Challenge is required because you are requesting a wildcard cert. Without the wildcard the http and tls-alpn challenges are possible.
Certbot is the ACME Client and Let's Encrypt the ACME Server. While Certbot makes the cert request it is the ACME Server (Let's Encrypt in this case) that performs the challenges against the public DNS. Once they succeed the cert is issued and Certbot retrieves it.
What sort of automated updates would this do to my dns records? We don't make frequent changes, and when we do, it's on the master, manually.
Certbot makes the csr request, does it also generate the csr, or does that have to be done, then certbot sends the request?
I'll have to read on those challenge types.
We are only doing this as with certs being shortened so drastically, we decided to look into automating. Otherwise, once a year for a handful of certs wasnt a problem.
Validation for the certificate (when requesting a wildcard cert) requires adding a TXT record of a specific value, which is different for every renewal, and then removing that record once validation has succeeded. This needs to be done about every two months.
Yes. In normal use, you should never need to deal with a CSR; your ACME client (whether certbot or something else) would ordinarily handle that automatically for you.
Consider not using certbot, though. It's better to use a server that integrates an ACME client (e.g., Caddy), or has one available as a module (e.g., mod_md for Apache), or is behind a reverse proxy that integrates ACME (like Traefik or HAProxy). Standalone ACME clients just add another thing to maintain and potentially fail.
So, just make my own ACME client. I have a server that used to do a number of things, but now all it's for is generating CSR, which are then used to request a wildcard.As long as this server has a path to our cert authority, do you think that would work? Almost all the sites are internal.
Just trying to wrap my head around this. Doing a wildcard yearly, was no big deal!
That is a fairly involved undertaking when there are so many good ACME Clients already existing. The ACME protocol regularly evolves. What benefit would you get from your own client that you can't get from an existing one?
If you have an RHEL server why not just run an ACME Client there?
Who is your DNS provider? You can do manual cert requests with many ACME Clients but automating it is a big benefit of ACME (Automated is what the A stands for )
The lego client supports many DNS providers as does acme.sh client. These are both commonly used. Certbot is also commonly used but does not as easily support the wide variety of DNS providers as these other two. See: ACME Client Implementations - Let's Encrypt
If you can wait a little bit there is a new challenge called DNS-PERSIST where you can place a TXT record in your DNS just once and have it prove control of the domain for multiple (even perpetual) cert renewals. Let's Encrypt has targeted Q2 of this year for its support in production but I don't know which ACME Clients will support it right away.
Perhaps do a manual cert request now and once DNS-PERSIST is readily available start automating with that. I'd recommend lego client for that case as it has tended to get newer features quicker than some other clients.
What do you do with the certificate once you get it from GoDaddy?
That's what I mean, just run a client on my rhel server. We do most of our own dns for external and internal.
Once the csr is sent to GD, we get the wildcard.crt and bundle.crt. From there, I swap them out on whatever systems needs it, or create a jks for a few servers.
What is the question then? If you need a wildcard cert you have to satisfy a DNS Challenge. To automate that your ACME Client needs to add/delete a TXT record to the public DNS for that domain. I think we already covered this.
You don't need to create a CSR. If the challenge succeeds your ACME Client places the cert files on your local RHEL system. You can deploy those as you have been.
Initially, does this client have to run on a dns server, and if so, would it run on the master or a slave dns server? This was the original question.
Or, would I be able to make this dns-persist TXT record, place the dns-persist on a different server that is running the client? It's sounding like it'll have to be on a dns server, so I am hoping it can run on a slave, which would keep the master more isolated.
I'm sure I sound dumb, but I haven't had to ever look into automating certs.
You usually wouldn't run it on the DNS server itself (though you probably could), it just needs to have access to some sort of API to allow for updating the DNS records. What DNS server software do you use? Many might support changes through RFC 2136 support, which certbot and lego and such support using.
My recommendation for you then, if you want to keep using a wildcard cert, is to set up Certbot with its RFC 2136 plugin on some system (maybe even a VM dedicated for it, but it certainly doesn't have to be). That documentation describes a bit about how to configure BIND to support dynamic updates from certbot for the TXT records. Then you can use certbot's --deploy-hook to run a script to publish the wildcard certificate and private key wherever they need to go whenever they get updated.
The other option would be to rework how you're thinking of certificates entirely, not use wildcards, and just have each system run its own client and manage its own certificates for just the names used for that system. But I understand not wanting to change too many things all at once.
)