Skip to main content

AutoSSL Validation Process

timwoolfson
Hi, It seems that the AutoSSL process as at WHM 64 build 29 first queries for a temporary file. If it gets 403 forbidden, it fails without ever writing the temporary file. Why doesn't it write the file first. Then query it? If it did that it could work with people who have their .htaccess rules set-up to forbid (403) access to non-existent files. WordPress with en-gb.wordpress.org/plugins/all-in-one-wp-security-and-firewall behaves like this for example (more than half a million installs). Grateful for any feedback, Tim.

Comments

10 comments

Date Votes
  • 24x7server
    Hi, The AutoSSL first verifies your account, then write a file in it for the Comodo to verify that the account is on this machine itself that the cPanel has send in a request for on SSL.. If you have .htaccess blocking this, then SSL generation will continue to fail. You have to make sure that the .htaccess allow this .txt file to be browseable, at least for the time being the SSL is generated..
    0
  • timwoolfson
    Thanks for trying to help but you miss the point - I've better formulated my suggestion as a feature request AutoSSL should write text file before access check I can turn off AIOWPS so that autossl works but that's mental - AutoSSL should write the file before trying to access it. Forbidding attempts to access non-existent files seems sound from a security perspective to me. Alternatively perhaps AUTOSSLcould be refactored to use DNS to establish request authenticity...
    0
  • cPanelMichael
    Hello, Are you sure the DCV text file is never generated? As I understand, it should generate first, but is automatically removed when AutoSSL fails on a certificate order. This is to prevent multiple DCV files in the document root in cases of repeat AutoSSL failures. Note the following feature under the "Domains" tab in "WHM >> Tweak Settings" allows for global DCV passthrough without the need to manipulate the .htaccess file: Use a Global DCV Passthrough instead of .htaccess modification (requires EA4) Thank you.
    0
  • timwoolfson
    kanban - in future please post a new thread unless your post is directly related to the original post - yours is tangentially related but muddies the water so far as the original post is concerned - a separate thread would have been better for both of us. Michael, thanks for your comments - I will look into the Global DCV rewrite - nonetheless, I can confirm that at the time that AutoSSL tests for the file - log excerpt follows - cPanel name and domain name have been rewritten to example but the domain / account in question is on the server and DNS configured, the file does not exist, if it did exist AIWOPS would allow the file to be read - I have checked - it is rightly blocking the request because the file does not exist - 404s are blocked as 403s. Please vote for the feature request if you are also having this issue AutoSSL should write text file before access check
    10:33:09 AM Checking websites for "example" " 10:33:09 AM The website "example.com", owned by "example", has a faulty SSL certificate (OPENSSL_VERIFY:0:10:CERT_HAS_EXPIRED NOT_ALL_DOMAINS ALMOST_EXPIRED AUTOSSL_READY_FOR_RENEWAL). AutoSSL will attempt to replace this certificate. 10:33:09 AM WARN The domain "example.com" failed domain control validation: The system queried for a temporary file at "http://example.com/63A14725691C86DA179389AEB54D6BB8.txt", but the web server responded with the following error: 403 (Forbidden). A DNS or web server misconfiguration may exist.
    0
  • Infopro
    Separated Threads..
    0
  • cPanelMichael
    I will look into the Global DCV rewrite - nonetheless, I can confirm that at the time that AutoSSL tests for the file - log excerpt follows - cPanel name and domain name have been rewritten to example but the domain / account in question is on the server and DNS configured, the file does not exist, if it did exist AIWOPS would allow the file to be read - I have checked - it is rightly blocking the request because the file does not exist - 404s are blocked as 403s.

    Feel free to open a support ticket using the link in my signature so we can take a closer look. Thank you.
    0
  • 4u123
    Can you please confirm whether access to these text files is required for renewal as well as the original validation? As you'd expect, may customers have htaccess directives that don't allow access to this file, so when validation fails we need to intervene. Is this going to be a continual problem upon renewal too? Is there an Email notification for failed validation? I'm wondering why the validation doesn't simply check that the domain resolves to an IP on the server that is requesting the certificate?
    0
  • cPanelMichael
    Can you please confirm whether access to these text files is required for renewal as well as the original validation? As you'd expect, may customers have htaccess directives that don't allow access to this file, so when validation fails we need to intervene. Is this going to be a continual problem upon renewal too?

    Yes, it's required for the renewal as well as the original request. The following feature under the "Domains" tab in "WHM >> Tweak Settings" allows for global DCV passthrough so that customers do not need to manipulate their .htaccess files: Use a Global DCV Passthrough instead of .htaccess modification
    Is there an Email notification for failed validation?

    The following notifications are available as of cPanel version 68: Urgent DCV Updates This Week | cPanel Blog Thank you.
    0
  • 4u123
    Enabling "Global DVC Passthrough" in tweak settings doesn't resolve this problem. We are not discussing the issue of cpanel automatically making changes to .htaccess files. This discussion is specific to the issue surrounding .htaccess directives that inadvertently prevent access to the /.well-known/pki-validation/ file - or as the OP points out, it seems if the initial check results in a 403, the file is never written and validation doesn't even start. As they said, it is reasonable to forbid access to non existent files. The ultimate goal here is automation of this process, but as the OP points out, anyone using their own htaccess directives to prevent access to filetypes, or various .htaccess based security plugins, of which there are hundreds of thousands of installs, are going to need manual intervention - and currently we don't even get notified when this is required. For a provider with lots of servers, once the use of AutoSSL becomes the norm, this could become a real pain, having to make changes to many clients htaccess files every time their DV cert needs creating or re-validating. The above suggestion, to create the text file before checking to see if it exists doesn't make much sense though. I assume the process of checking the existence of the file is required, prior to validation, modification, or creation if it doesn't exist - it just seems the script doesn't take into account the fact that access might be explicitly forbidden. So perhaps the script should handle that result differently? Although there are still plenty of other situations in which this process could fail. Only time will tell if it is going to become a major issue.
    0
  • cPanelMichael
    This discussion is specific to the issue surrounding .htaccess directives that inadvertently prevent access to the /.well-known/pki-validation/ file - or as the OP points out, it seems if the initial check results in a 403, the file is never written and validation doesn't even start. As they said, it is reasonable to forbid access to non existent files.

    There's no functionality to account for those types of .htaccess rules at this time. I encourage anyone experiencing this issue to vote and add feedback to the following feature request: AutoSSL should write text file before access check Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post