I have IPv4 and IPv6 records pointing to my domains,
My routine of testing, is to redirect all tcp 80/443 to my local machine on my (ipv4) firewall, and run a cert request to the testing server.
This is easilly scriptable, and works great.
It seems to fail on several of my domains now, and they all have ipv6 AAAA records.
I can’t redirect ipv6 traffic, so please, make an option to use ipv4 only in validation.
I can see in my firewall log that you try to access my server with ipv6 during my test renewal.
I love the ipv6 support, but be aware that you can’t always easily redirect ipv6 traffic temporarily in a firewall.
Hi @scifibob,
As I discussed in another thread, I think the CA folks may believe that giving certificate applicants too much control over the validation process is a security risk because it facilitates attacks.
For example, if I’m an attacker who can perform a routing attack on an IPv4 network but not on an IPv6 network, if the CA lets me say to ignore the existence of the IPv6 network for validation purposes, then I can take advantage of my attack to get a misissued cert, even though I might not have been able to do this otherwise. After all, the whole point of the DV process is that we don’t know at the outset that the people who are requesting certificates for a site are, in fact, the operators of that site, so we should not easily believe things that they tell us about how the site “really” works or how it wants to be validated using something other than what it’s said in DNS.
(However, this security concern might be addressed by allowing a DNS record that makes this request rather than an ACME protocol feature.)
2 Likes
Okay, I see the point. I haven’t digget too much into IPv6 vs IPv4 differences regarding authentication, so I’ll guess I’ll try the dns way. I have full control over me dns anyway.
I just hoped not be using that way, since it requires scripts to update the server, and nsupdate scripts means I as a developer need to make a whole new toolbox. And there is that thing around record/SOA refresh time.
If you do have full control over your DNS, you might want to use the DNS-01 authentication method to get a certificate, which doesn’t require an inbound connection at all—just setting a DNS record indicated by the certificate authority.
Yeah, I just need to get certain my dns provider pushes the record out in time.
This is my primary problem with dns, not all providers update immediately.
And that is what I want, an immediate update of ownership. It seems that there is currently NO service out there to verify a domain ownership immediately, or maybe the big guys don’t want there to be one.
If you’re okay with deploying another piece of infrastructure, something like acme-dns might be a good fit if you’re with a DNS provider where propagation delays are hard to estimate. The way it works is that you add a CNAME record instead of an actual TXT record for the _acme-challenge subdomain, and point that to a separate domain that’s served by the acme-dns DNS server, whose sole purpose is to solve ACME dns-01 challenges. This could be a separate domain or just a subzone of your domain (i.e. acme-validation.example.com). The project’s GitHub page has more details and instructions.
1 Like
Sounds like the perfect solution for me. I will check into this.
Thank you, pfg.
I finally went for a wildcard cert from AlphaSSL, I really did not have the time for all the hassle of getting all of my subdomains validated by LetsEncrypt.
It’s really a lot of work when you constantly are making new subdomains due to developing, etc.
And the solution pointed to me by pfg just confirmed my doubts, that implementing LetsEncrypt involves installing all kind of garbage to your system that you don’t know what’s doing.
I prefer a clean solution. I make a private key and a csr, and some service out there generates the rest, based on a trusted CA.
Hi @scifibob,
I agree that Let’s Encrypt is not very well optimized for sites with a very large number of subdomains, especially because we don’t offer wildcard certificates. There are lots of sites that may be better served with a wildcard certificate from a different CA, and I think there are plenty of good use cases for that.
The biggest reasons that we’ve focused on installable client software as a means of using Let’s Encrypt are our focus on automation and automated renewal, and the fact that we’ve targeted people who have never had a certificate before. As we’ve seen quite a bit on this forum, many of our users don’t know what a CSR or private key are, and have never edited their web server configuration before. It seems like these users are quite reliant on software applications to help perform configuration for them, and they represent a major chunk of webmasters out there.
For people who are already very familiar with PKI and don’t want a lot of automation, a good minimalist Let’s Encrypt client solution might be any of the bash clients
which are small, have few dependencies, and don’t perform very complex automation.
For people who don’t want to install any software at all,
replicates much of the experience of using a conventional DV CA via a web interface (but with no payment required).
If you need a certificate in the future for a use case where wildcards aren’t important, I hope you’ll consider trying one of these approaches.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.