There are tons of complains in the forum about failures of Virtualmin's Let's Encrypt implementation. One of the reason of why Virtualmin users encounter so many errors is that Virtualmin sends certificate request for both www and non-www versions of domains.
While that might frequently work ok for top level domain names, it almost never does for sub-domains, especially for cases which rely on DNS-based verification. Because even if the top level domain's DNS is hosted on Virtualmin server, you need to preliminarily create a respective nameserver, so that DNS-verification sees the www version of sub-domains (which are in fact sub-sub-domains).
And thus, when verification through port 80 or 443 (this one is missing in Virtualmin) is not available and your only option is DNS-based verification, you simply can not use what Eric told in https://www.virtualmin.com/comment/782517#comment-782517:
Now that SSL is becoming more common, there's a feature for enabling Let's Encrypt for all domains as they are created. That feature can be enabled in System Settings -> Virtualmin Config -> SSL Options -> "Request Let's Encrypt certificate at domain creation time?".
to automatize the process, because it always gives:
DNS-based validation failed : DNS zone www.sub.domain.com does not exist on this system
However, you can pass through the verification if you go to Manage SSL Certificate and instead of automatically selected www and non-www versions of the domain in Domains associated with this server
option, you use the Domain names listed here
option and indicate only non-www version of your sub-domain.
And this headache can be easily treated by making Virtualmin send requests for only non-www version of domains and sub and sub-sub-domains. Users always can add www versions if they want, but please do not make automatization of the process impossible without hacking the Virtualmin's code.
Comments
Submitted by yngens on Thu, 09/07/2017 - 15:25 Comment #1
Witnessing *min team was ignoring our report bugs, support and feature requests when we were not subscribed to any paid product, we've proceeded to getting Virtualmin 100 Annual License (vm100).
However, our requests still get ignored and I am now in doubt should we just cancel our subscription, requested refund and be away from *min at all or will you finally start to understand that leaving such requests more than 24 hours is inexcusable however busy you, guys, are. Just drop couple lines acknowledging you've read it, give some assurance to your customers that their requests are on your radar.
I understand you have a lot on your plates, however we, as a hosting provider, also do have lot's of responsibilities before our customers. And your inability to address the issues of your software dramatically effects our business down the chain when we seriously start considering alternatives. I touched this problem several times in the past, and every time I hoped you'll get better. Unfortunately, you are not. Hey, James, don't you think it's time to expand if you can't cope to do things all by yourself?!
Submitted by yngens on Thu, 09/07/2017 - 15:27 Comment #2
I'll wait for another 24 hour and proceed to cutting all ties with you, guys. We were going to launch our second business line with "SSL everywhere" approach, but unfortunately it is simply not possible with Virtualmin at current state. And when we indicate the problems, which are in fact so easy to address, you guys keep ignoring on your customers. Red flag.
Submitted by Jfro on Thu, 09/07/2017 - 15:47 Comment #3
Uh sorry guys? https://www.virtualmin.com/comment/782517#comment-782517: There about 1 day ago: : "" Submitted by JamieCameron on Wed, 09/06/2017 - 18:45 Comment #7
This situation will be handled properly in the next Webmin release. ""
Better to wait a little more and have a working solution ...
( letsencrypt scripts did have more probs on more panels, not only here while it is free and so populair doesn't mean it is as easy to do it 100% right for everyone and every situation, they are working on it as missunderstanding for subdomain things is not only here, we use in other panel not subdomaining dns, but own seperate zone for therefore real separate own domainname for that sub...)
Submitted by yngens on Thu, 09/07/2017 - 15:51 Comment #4
Ah, James promised to fix it after I marked that issue as closed and created this one instead, and that's why it didn't show on my list of issues (which is configured to show only Open issues by default).
James, sorry for being so critical and thank you for agreeing to fix the bug, but then please pay attention to how you, guys, organized this error reporting system - if issue is marked as closed then user needs to do one extra step to dig into it. So please reply to open issues, not closed ones.
Submitted by yngens on Thu, 09/07/2017 - 16:03 Comment #5
Jamie, we are building a fully automated "SSL everywhere" system and terribly need this fixed ASAP. Can you give ETA of next release? Can we get dev version sooner than it's released to public as we really need to run lot's of tests and get to other relevant issues which might come up?
Submitted by Jfro on Thu, 09/07/2017 - 18:01 Comment #6
Achja we zijn allemaal wel eens moe. ;)
Yep we all could be a litle bit tired sometimes ok ;)
Submitted by yngens on Thu, 09/07/2017 - 18:19 Comment #7
Jfro, it is not about being tired, it is about them replying to closed tickets and leaving open tickets totally unattended.
Submitted by JamieCameron on Thu, 09/07/2017 - 23:33 Comment #8
I can get you a devel version with this fix tomorrow if that would be useful. Or you can apply this patch : https://github.com/webmin/webmin/commit/b4ada44f45bf33bfef3bb2923bdd1e52...
Note that this only applies to DNS-based validation - normally that isn't used except as a fallback, as web-based validation usually works.
Submitted by yngens on Fri, 09/08/2017 - 18:16 Comment #9
Jamie, thank you very much. I'll wait for tomorrow to start testing this again.
Submitted by yngens on Mon, 12/04/2017 - 21:00 Comment #10
After all this one was not fixed and I believe should be closed in favor of https://www.virtualmin.com/node/54553