Yeah, I don’t like how prone to failure the wizard is on this front. I talked about it with @Ilia and Jamie, but I guess it’s still in there. I think we need to roll it back. It’s so unlikely to ever work right on first install…it assumes so many things are going to be configured right that the vast majority of users have no idea how to get right. It’s just a mess.
Yeah, I was against adding it, honestly, and I still think it’s not worth the high likelihood of failure. I thought I’d convinced @Ilia and @Jamie to make it fail gently (i.e. not look like a serious error, not prevent proceeding, make it clear what happened and why, etc.), but I guess we’re still not on the same page about that.
Does failure to request the LE cert completely break the install wizard process? It should be just a warning that you can skip.
Virtualmin is unfortunately in a bit of a catch-22 situation here, as many browsers complain if an HTTPS site doesn’t have a valid cert. But it’s hard to get a cert from Let’s Encrypt until at least one domain has been created and properly registered.
If the wizard LE request failed, there is no reason to expect SSL on the host domain website. If it failed, you’re not getting valid SSL, so there’s no reason to do anything about SSL. The user just needs to be informed about their next steps, and reassured that this isn’t a terrible thing they need to panic about (because anything that can be interpreted as an error during the install/wizard will be treated as a thing to panic over…some folks give up immediately and go try something else).
The main concern (once you know what’s been going on and that the errors were due to sub-domains that you don’t want or use) is that you’re then locked out of attempting to get the SSL certs from Lets Encrypt for a period of time.
Does this solution solve that, or is it just a way to tidy those specific errors? Because if its only hiding the error, users are going to again try and get SSL and it’ll fail again because of the rate limits.
Personally, I’d rather be able to tell the system that I don’t want any sub-domains at all earlier in the setup process - which solves the core issue (requesting 4 domains that are invalid, which ends up blocking you from further Lets Encrypt requests)
Only posting here fo readers having problems a kind of workarround.
If you use upfront ( temp) a external DNS service provider to configure dns then use that, also for all needed “sub” domains.
Take care of the TLS times that dns is resolvin every thing.
This is only workarround.
If using external dns as default then you have to take care that all is resolving well upfront, then there should be no problems i think right?
(Sofar my own experience (not this new version setup) was when dns wasn’t resolving yet then problems.) ( also then the browser cache, htts if it was set before once for that domain , dns cache , dnssec…and so on…)
Yeah, you could set all the subdomains up - but we have never used any of them. We just plain don’t want them at all (the mail. etc). While we can change the option on “new servers” once Webmin is set up, so that we can provide a manual list - we can not do that in the wizard. You can’t tell it “just the TLD”.
@Jamie as we discussed earlier today, this would only break if you use mydom.com:10000 in URL and mydom.com as default domain in the wizard. The reason is that miniserv.conf gets a new SNI records, for that new default domain, like ipcert_mydom.com... and when Webmin configuration is applied, miniserv starts serving this newly self-generated certificate. This is where a new confirmation is required on the browser side to continue using the page.
The best solution in my opinion is simply not to restart Webmin at this point, and continue serving existing self-signed certificate.
As I don’t use the Host default domain other than for managing the server, I found it best to select to make a new self certificate, then once the wizard is finished, I disable DNS and then run LE and it just gets a certificate for the domain without all the alias’ eg webmail etc - which otherwise fail.
I also have my DNS on a separate dedicated server.
So it now works for me as it is, but I can see that other people might want the LE to work in the Wizard.
Oh, wait! We mustn’t add to a default domain any aliases! I wasn’t aware that we’re still doing it, as I remember we already discussed it in the past and I though we stopped adding any aliases to a default domain!
@Jamie, also, as we now support Cloud DNS Providers, I assume it would make sense to ask on the wizard if a user hosts DNS locally or using Cloudflare, Google Cloud DNS or Amazon Route 53. If the DNS hosted locally, then go straight to default domain setup, but in case of cloud DNS provider, let a user to configure it on the next wizard step? What do you think about it?