Looks like with this my HTTP-01 and DNS-01 concerns can be mitigated...am I right?
I'm still not clear on what concerns you have.
5 Likes
Caddy with Let's encrypt also requires NGINx or the purpose can be achieved with Caddy and Let's encrypt without http or dns challenge limitations?
your suggestion here talks about acme-dns...this gives me a ray of hope that my automation can flourish without being stuck because of http or dns challenge issues at hand...
Caddy is its own web server, and doesn't require nginx. If you can have it in front of your "real" web server, it will manage certificates automatically, through HTTP or TLS-ALPN.
If you want to use Certbot with DNS challenges instead of Caddy, then yes you'd want acme-dns, with the proper delegation from your name to it. It has quite a bit of documentation that I recommend you read through.
5 Likes
it would be really great if you can provide some useful links to read through....only if you have something handy...
The readme file that their repo has goes through a lot:
It links to an article hosted by the EFF describing an example way of using it:
I personally haven't used acme-dns myself, though, so maybe other people here could give you better pointers.
7 Likes
What would you recommend to go with:?
- Let's encrypt and Certbot with acme-dns, or,
- Let's encrypt and Caddy with TLS-ALPN
I would recommend Caddy, just in general in front of anything "legacy" or "weird". The fact that it will handle your certificates automatically is just one of its nice features.
5 Likes
thank you
3 Likes
With Caddy, do I need to install Caddy on all the 40 nodes/servers of my proprietary application or a centralized dedicated node/server where certificate is renewed automatically through Let's encrypt and pushed through Ansible to all 40 nodes.
I think you'd want to have your Caddy in one place (or a small cluster), which then does the load balancing by reverse proxying to your application. But there are probably many ways of doing it. I'd suggest you look through its reverse_proxy documentation; it has a lot of ways of handling load balancing and I think you're probably getting into questions that are really specific to your application (and why it would need to be on 40 nodes in the first place).
I need to get back to my day job; good luck!
6 Likes
IMHO, it's best to terminate TLS on a gateway/load balancer.
If you have to configure the appservrs with TLS, my suggestion is:
- Use a specific machine to request certificates with DNS-01 challenge
- Use a CNAME on the
_acme-challengerecord to delegate it to a system without the technical/security constraints - Use a post-deploy certbot hook to push the certificates to the nodes
6 Likes
I have a limitation in using DNS-01 and HTTP-01 challenge. What you are suggesting is through certbot and will this resolve my limitations?
Thanks
1 Like
The DNS-01 challenge allows you to delegate the acme challenge record (and only that record) from the primary dns system onto a secondary system. You should be able to use that to get around any security or technical requirements that prevent you from manipulating records on the primary DNS. A privileged administrator can set the delegation record on the primary DNS on setup, and all challenges will then occur on the secondary DNS system - which is on a system/account that exists solely for the purpose of answering these challenges.
Aside from addressing your security issues, this type of setup is consisted to be the secure way to implement DNS-01.
7 Likes
2024/10/23 14:51:38.774 INFO tls.issuance.acme.acme_client trying to solve challenge {"identifier": "FQDN", "challenge_type": "http-01", "ca": "
https://acme-staging-v02.api.letsencrypt.org/directory"}
2024/10/23 14:51:39.709 ERROR tls.issuance.acme.acme_client challenge failed {"identifier": "FQDN", "challenge_type": "http-01", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "87.51.89.53: Invalid response from
http://FQDN/.well-known/acme-challenge/n3pb-6cd9MXRFseUxhstTJL6oekrGSiFcCyBQi_b51Y:
404", "instance": "", "subproblems": }}
2024/10/23 14:51:39.709 ERROR tls.issuance.acme.acme_client validating authorization {"identifier": "FQDN", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "87.51.89.53: Invalid response from
http://FQDN/.well-known/acme-challenge/n3pb-6cd9MXRFseUxhstTJL6oekrGSiFcCyBQi_b51Y:
404", "instance": "", "subproblems": }, "order": "
https://acme-staging-v02.api.letsencrypt.org/acme/order/168355333/19931913163"
, "attempt": 2, "max_attempts": 3}
2024/10/23 14:51:39.709 ERROR tls.obtain could not get certificate from issuer {"identifier": "FQDN", "issuer": "acme-staging-v02.api.letsencrypt.org-directory", "error": "HTTP 403 urn:ietf:params:acme:error:unauthorized - 87.51.89.53: Invalid response from
http://FQDN/.well-known/acme-challenge/n3pb-6cd9MXRFseUxhstTJL6oekrGSiFcCyBQi_b51Y:
404"}
2024/10/23 14:51:39.709 ERROR tls.obtain will retry {"error": "[FQDN] Obtain: [FQDN] solving challenge: FQDN: [FQDN] authorization failed: HTTP 403 urn:ietf:params:acme:error:unauthorized - 87.51.89.53: Invalid response from
http://FQDN/.well-known/acme-challenge/n3pb-6cd9MXRFseUxhstTJL6oekrGSiFcCyBQi_b51Y:
404 (ca=
https://acme-staging-v02.api.letsencrypt.org/directory)"
, "attempt": 1, "retrying_in": 60, "elapsed": 4.065562122, "max_duration": 2592000}
Hi guys, I tried Caddy and TLS ALPN challenge...got this issue...any suggestions as in what has gone wrong
Those error messages are for an HTTP-01 challenge. Not TLS-ALPN. You should review your config.
There are also two different IP addresses shown. Does that domain name point to a load balancer or similar? If so, can you explain more about that? Because every IP in the DNS for that domain must be able to reply with the challenge data. It usually takes a careful approach to make those work.
Using Caddy I would expect to see the DNS IP pointing to the Caddy used to reverse proxy to your origin servers
6 Likes
We have a FDQN that has Sub FQDNs which points to two or multiple hostnames