I'm in the process of provisioning a new server to host customer web sites. We migrated to SolidCP from WSP when 1.3.0 was released and that process went smoothly. This new server is running Windows Server 2016 and we are not using centralized SSL certificate store.
Almost everything appears to be working properly, but I'm having a strange issue with LetsEncrypt. I ran a series of tests to try to determine what may be happening.
I created a new website in SolidCP and made sure that DNS was propagated and working properly. I then tried to issue a certificate using the LetsEncrypt "Install Certificate" button on the SSL tab.
At first glance, this process appeared to work. A new certificate for the site appeared in the Web Hosting certificate store. SolidCP reported that the certificate was installed. However, the "Installed Certificate" tab did not appear in the interface. I clicked away from the web site in SolidCP and went back in and clicked the SSL tab. There was an existing certificate detected, which appeared when I imported it.
However, on this first attempt, the site was stopped because when Lets Encrypt added the SSL bindings to the site, it used SNI with 0.0.0.0:443 for each of the host headers.
I noticed that during the enrollment process, the app pool for SolidCP Server recycled due to high virtual memory usage, so I deleted the certificate and tried again with the same result (The pool didn't recycle this time).
The site's HTTP bindings were to *:80:<host header>. I changed the bindings on the site through IIS manager to the proper NAT IP address for our server and tried again. This time, the certificate installed, and LetsEncrypt set up bindings for <IP Address>:443 for each of the host headers. SolidCP still did not display the installed certificate, I had to go out and back in and import it for the certificate to show up on the SSL tab.
It appears that the LetsEncrypt client is using 0.0.0.0 to build its bindings when it sees bindings on a site for "All Unassigned". I currently have this server configured
Have others experienced the same issue? I'd sure like to have this functionality available for customers, but want to make sure that it works without any weird problems.
Does anybody have any thoughts on what may be going wrong here?
Hello,
The first bit of having to go out of the Tab and back in where it displays an import cert tab is correct, this should be fixed in the next SolidCP release.
for the bindings: LetsEncrypt win Simple client (which solidcp uses to do it's bidding) prefers you to have * :80 bindings (with hostname set).
You can double check in the Portal if your iis settings at the top has the All ip's selected in the ip drop down.
This should then create suiteable bindings of *:443 with hostname (sni) set.
Now it's worth mentioning to enable sni in the iis settings in the portal (only available for IIS 8 and up).
But i assume thats already set since the SSL tab is showing up.
You could optionally check what it's doing by running the LetsEncrypt win Simple client manually and look for any comments or questions (to work properly it should just run without having you to press any yes/no questions etc).
Regards,
Marco
Hi Marco,
Thanks for the feedback. The IIS settings for this server do have SNI enabled, and the "Web Sites Shared IP Address" is set to "all unassigned".
When the site was created by SolidCP, it had the appropriate bindings (*:80:<host headers>).
When LetsEncrypt runs, it ends up adding bindings for 0.0.0.0:443:<host headers> instead of *:443:<host headers>. SNI is enabled on the bindings, but IIS stops the site and IIS-W3SVC throws System event 1172:
The World Wide Web Publishing Service (WWW Service) did not construct valid URLs for virtual site 6. Therefore, the virtual site 6 will be stopped. This can be caused by invalid characters in the site bindings. The following characters are not allowed in a site binding: """ "/" "\" "[" "]" ":" "|" " " "<" ">" "+" "=" ";" "," "?" "*" "%" "#" "@" "{" "}" "^" "`". To fix this problem please remove invalid characters from the site bindings.
If I fix the bindings manually, I can restart the site.
I was just wondering if there was a configuration option to change the way it sets bindings, or if this is an issue with LetsEncrypt on Windows Server 2016. IIS manager was warning about the server not having a default SSL site for non-SNI compliant browsers, so I deleted the certificate and created a default
I saw a similar question here in the forum so I ran LetsEncrypt manually with the --verbose switch to see if anything useful showed up there. Running LetsEncrypt from the command line gave me the same result, it created bindings on 0.0.0.0 instead of *, which caused the site to stop until I fixed the bindings manually.
It seems like a problem with the LetsEncrypt software, which I know you all didn't write, so I'm definitely not blaming you all. I did check the GitHub site for the program and don't see any open issues that appear related to this.
Other than this one issue, it's working great, but the need to have an administrator manually fix the site bindings makes it difficult for us to use in production.
Hello,
Your indeed correct that we didn't write the LetsEncrypt win Simple client.
SolidCP just makes use of it.
Though that being said we did test it with Windows 2016 without issues.
In our scenario we did leave default website intact (including the 443 binding), and we do not have any dedicated ip's anywhere.
You might want to try to reproduce that.
without it i did assume the client should push out an issue (log) but from your description that didn't gave anything usefull?
Is there anything (warning or information) in the event viewer application log?
Regards,
Marco
Hello,
Your indeed correct that we didn't write the LetsEncrypt win Simple client.
SolidCP just makes use of it.
Though that being said we did test it with Windows 2016 without issues.
In our scenario we did leave default website intact (including the 443 binding), and we do not have any dedicated ip's anywhere.
You might want to try to reproduce that.
without it i did assume the client should push out an issue (log) but from your description that didn't gave anything usefull?
Is there anything (warning or information) in the event viewer application log?
Regards,
Marco
