Currently, AutoSSL is designed to only issue certificates to servers that are hosting the website in question (checked via DCV test). This limitation has understandable advantages, but as a result, sites that route their DNS through CDNs are put at a significant disadvantage. Essentially, there is no way to auto-renew a certificate for a website in this position.
It is easy enough to temporarily disable the CDN, manually reissue the certificate, and then re-enable the CDN, but when managing a large number of sites, the need for an improved validation feature (perhaps DNS-based) becomes clear. I don't have any specific suggestions as to how the functionality could be implemented, but as CDNs are rapidly gaining in popularity, I imagine this will be a highly sought-after feature.
I like this idea 
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!