@Euclid in that case they could also issue wildcards.
Any news on where this might sit on the priorities list now that you’re in public beta?
2 Likes
It’s very high on our priorities list now. 
13 Likes
that’s nice then I will be able to get my certs soo without hassle coz doing manual over SSH (windows PC with XAMPP, nothing supporting that) from my raspi for like 14 domains is annoying, I rather just bind a has of my public key or whatever to it.
[quote=“jsha, post:23, topic:604”]
It’s very high on our priorities list now. 
[/quote]that is awesome news 
1 Like
it truly is. also if possible try to make it a static identifier liked to the account so as long as I dont take the record out that I can get my certs, also include subdomains please.
You might want to think this through. It’s a horrible idea in the form you are suggesting.
why that?
it’s not as if someone can inject their account keys into my DNS.
Bad option to allow it for an unlimited time period. It might be okay for 7-14 days, though and only for a specific account public key to issue.
But if the certificate authority isn't checking the record against some other signifier like the account public key, then anyone could get a cert for your domain as the validation would continue to work.
1 Like
well LE uses the account keys for keeping the validation valid for 10 months altrady that is a fact, so I think they will check they acc keys. and if LE would check whether I have the correct privkey for the pubkey in the DNS, then (as long as I dont lose my keys) it should be pretty secure.
+1 for DNS verifications
It will be super easy to implement with Amazon Route53
Am I missing something here?
The authenticator service is already using a dns A record to verify the IP for ownership. How much extra programming is required to check a SRV record?
If someone else has access to my dns setup, I would guess that they also would have no problem adding false A records.
2 Likes
I have been following letsencrypt for a couple of days now and looking through the available information I must say THANK YOU! thank you for the great start of (what I hope will be) great service in the future and I have also already been looking towards implementing letsencrypt certificated all around our shared hosting but for that I would really love the DNS verification option; hope this will be implemented soon.
Again thank you for the great work and keep it up!
3 Likes
+1, need this badly.
making an API call to route53 to create an SRV or TXT record is much easier than file based auth.
5 Likes
here, too. Would strongly prefer to authenticate via DNS.
Excellent, it’s so much more convenient than uploading files to the webserver. Hope this gets released soon!!
+1 Looking forward to the release of this functionality as this method would be far easier for us using Route53
i would prefer dns validation, also.
I too would like to see some sort of dns option soon
especially if it allowed for cname following
(as atm placing files in all cluster members for all domains that are clustered under the san cert aint easy)
the cname following would just be nice plus for us as hosted websites are done via us or them cnaming www.whatever at the cluster (as some people hosting with us want their dns to stay with them)
and if auth could also be telling them to point a cname at a location in our zone we can put the tokens to show we admin the san-certs/clusters etc it would be sweet
as currently we only provide http to clustered customers as organising a san cert to cover so many domains cost effectively is a no-go (as most of our customers are charity/non-profits and have no real case for spending on https, but we’d like to offer it as default if we could get SANs working effectivly
Reminder: per our Community Guidelines, don’t post +1’s to indicate you agree, since it makes it harder to see posts with new info. Instead, please like (
) the first post in this thread. Thanks!
2 Likes