AutoSSL: DNS challenge validation
Let’s Encrypt allows for DNS challenge validation as an alternative to HTTP/S challenge validation.
The DNS method allows certificates to be properly issued and renewed even if the HTTP/S method fails due to redirections, custom rewrites, and other factors.
For this reason, we currently try (via a custom client) the DNS method first, and only switch to the HTTP/S method if the DNS method fails. We would like to switch from using a custom client to AutoSSL, but the latter only supports the HTTP method.
Once DNS challenge validation is implemented, we recommend offering the following options in WHM:
- Try DNS challenge first, then HTTP/S challenge
- Try HTTP/S challenge first, then DNS challenge
- Try DNS challenge only
- Try HTTP/S challenge only
This could be set on a server-wide, per-package, per-account, and per-domain basis.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
cPanel & WHM Version 74 has reached the CURRENT tier, and include DNS-based DCV! Update to v74 now to see this change, and give it a quick test-spin!
cPanel & WHM Version 74 has reached the CURRENT tier, and include DNS-based DCV! Update to v74 now to see this change, and give it a quick test-spin!
Currently it's unlikely that we'll get this specific request answered anytime soon, but I wanted to share one change we are making, and one thing that might help. Adjusting to https verification would be a significant amount of development time (our current estimation is 2 sprints of development time, which is around a month for us).
However, to help rectify the problem we have added some functionality in version 60 that will help with this. We'll be excluding redirects specifically for the verification files, which we've described a bit in this forum post.
We’ll be doing this automatically in version 60 for any domain that fails verification. If you have questions about that change, let me know in an email (not in comments here, since it's completely unrelated to this request).
Currently it's unlikely that we'll get this specific request answered anytime soon, but I wanted to share one change we are making, and one thing that might help. Adjusting to https verification would be a significant amount of development time (our current estimation is 2 sprints of development time, which is around a month for us).
However, to help rectify the problem we have added some functionality in version 60 that will help with this. We'll be excluding redirects specifically for the verification files, which we've described a bit in this forum post.
We’ll be doing this automatically in version 60 for any domain that fails verification. If you have questions about that change, let me know in an email (not in comments here, since it's completely unrelated to this request).
I like the idea of trying dns before editing htaccess. So try http, then https, then dns, and only then modify htaccess would be our prefered way to achieve this.
I like the idea of trying dns before editing htaccess. So try http, then https, then dns, and only then modify htaccess would be our prefered way to achieve this.
I would like to offer another perspective on why the development of a DNS or other validation method besides the normal http url based text file is critical to your plugin...
By not offering any other way to validation ownership is pretty limiting especially when you look at the ease of configuration for something like DNS validation. I understand it may take development time but you are severely limiting those people that can use the plugin.
You have applications like Django, CMSes, or other custom frameworks that do not always use public_html as the root folder, have specific URL rewriting schemes, WSGI, cached sites, or don't always use .htaccess. Those situations can leave a person with no way to use your plugin because they cannot allow your dynamic text file to be read.
The simple public_html/file.txt method of web page serving is no longer the defacto standard. Additionally, by moving to DNS you remove yourself from anything around the "web site document code" and anything a developer does for their website. And instead move your plugin towards the robust technology structure like DNS. Even sites like Google Analytics gives another way to validate ownership.
If you decide to stay with a .txt file displayed on a web page, then please just change how you do this to have a single unique generated file created that we can put in a location so you can see it. Exactly how Google Analytics and so many other sites do it to prove ownership.
I would like to offer another perspective on why the development of a DNS or other validation method besides the normal http url based text file is critical to your plugin...
By not offering any other way to validation ownership is pretty limiting especially when you look at the ease of configuration for something like DNS validation. I understand it may take development time but you are severely limiting those people that can use the plugin.
You have applications like Django, CMSes, or other custom frameworks that do not always use public_html as the root folder, have specific URL rewriting schemes, WSGI, cached sites, or don't always use .htaccess. Those situations can leave a person with no way to use your plugin because they cannot allow your dynamic text file to be read.
The simple public_html/file.txt method of web page serving is no longer the defacto standard. Additionally, by moving to DNS you remove yourself from anything around the "web site document code" and anything a developer does for their website. And instead move your plugin towards the robust technology structure like DNS. Even sites like Google Analytics gives another way to validate ownership.
If you decide to stay with a .txt file displayed on a web page, then please just change how you do this to have a single unique generated file created that we can put in a location so you can see it. Exactly how Google Analytics and so many other sites do it to prove ownership.
A thing to add is that the new Wildcard Certificates which are coming in January 2018 will require DNS validation you can read here https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html so another big reason for adding this before then.
A thing to add is that the new Wildcard Certificates which are coming in January 2018 will require DNS validation you can read here https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html so another big reason for adding this before then.
Hey all! DNS DCV has been added to the product with cPanel & WHM Version 74! 74 is in EDGE right now, and aimed at CURRENT later in July or early August. I recommend setting up an EDGE server (instructions on our blog) and give it some testing!
Hey all! DNS DCV has been added to the product with cPanel & WHM Version 74! 74 is in EDGE right now, and aimed at CURRENT later in July or early August. I recommend setting up an EDGE server (instructions on our blog) and give it some testing!
cPanel & WHM Version 74 has reached the CURRENT tier, and include DNS-based DCV! Update to v74 now to see this change, and give it a quick test-spin!
cPanel & WHM Version 74 has reached the CURRENT tier, and include DNS-based DCV! Update to v74 now to see this change, and give it a quick test-spin!
Replies have been locked on this page!