Possible bug when renewing certificate forces SNI on the wildcard hostname

Server OS: Windows 2012 R2

Disclaimer: I was on a previous version of Certify before this popped up, but am not sure which version.
When I renew a certificate, it forces SNI to be enabled on both the wildcard binding as well as the declared hostname binding by editing the applicationhost.config file to set the sslFlags to 1 instead of leaving it at 0.

                <binding protocol="http" bindingInformation="*:80:*" />
                <binding protocol="https" bindingInformation="*:443:*" sslFlags="1" />
                <binding protocol="https" bindingInformation="*:443:nms.REDACTED.co.uk" sslFlags="1" />

I have to have the named binding due to URL rewrite rules, but SNI is not required (I don’t care if it is on either), but turning it on for the wildcard breaks IIS.

In troubleshooting this, I have hit the weekly limit for LE, so further troubleshooting will take a bit of time, I wish there was a setting to enable using the LE staging environment when doing testing.

The settings for the certificate are as follows:
Certificate Domains:
Select Website: No IIS website selected
Certificate Deployment:
Deployment Mode: Auto

Under preview, it shows the following:
Deploying to all matching sites:

Action Site Binding
Update https binding WUG :443: SNI
Update https binding WUG * :443:nms.REDACTED.co.uk SNI

I hope this makes sense, and I’m just not doing something stupid…

1 Like

Thanks for reporting, I’ll investigate. Is there a reason you are binding hostname to * instead of leaving it blank? I think whats happening is it assumes there is a (non-empty) hostname to bind and therefore SNI would normally be used.

Note that when testing binding settings changes you can use Show Advanced Options > Other Options > Reapply certificate to just run binding updates without re-requesting the certificate.

The next version (beta coming very soon) supports multiple ACME accounts including LE staging.

Sorry for the delay, its been a busy few days. “*” is just what MS puts when there’s nothing there so there is something displayed. Even with SNI, the blank binding should not be getting sslFlag 1 as that is impossible, since there is no hostname to reference, it should always be 0. The hostname binding should really look to see what’s there, in case there is (for unknown reasons) SNI unchecked in the binding and leave it as set.

Thanks, this is indeed a bug and will be/is fixed in the next version. With a blank hostname in the binding it definitely works, but when it sees the ‘*’ it mistakes that for a hostname and tries to make it SNI. So the workaround is to remove the wildcard in the binding hostname.