Win-acme: ERR_CERT_COMMON_NAME_INVALID - new domain cert shows the wrong site name

[Stuart88]

Describe the bug
New certificate is being issued with wrong website name.

To see it in action...
Attempt to open https://thefivepeakschallenge.co.uk/
Notice SSL certificate failure
Check details to see:

NET::ERR_CERT_COMMON_NAME_INVALID
Subject: chinaglobalconnections.com // < ------ Wrong website?!
etc...

In IIS the site is assigned to the correctly named certificate (which I made in the usual way in win-acme), but the actual certificate seems to have been made in the wrong name. In fact, ALL my certificates have that name, but I've only just noticed now because this one new site is failing :S

Log
Unfortunately I can't log anything now because I've hit the limit for certificate creation this week (all in attempting to recreate the new certificate for my new site)...

Platform:

• OS: Windows Server 2014
• Version: 2.1.0, 64-bit, pluggable

[Stuart88]

I've updated to the latest win-acme and deleted all certs for my new website. Going to try again once the limit has reset.

(Also - a question - is it right that the latest win-acme silently crashes when attempting to create new certs for website that have hit the rate limit?)

[webprofusion-chrisc]

Hi, there is no Windows Server 2014 so perhaps you mean 2016?

Something you really need to watch out for with certificates on Windows is that one IP address can only be bound to one certificate (on https port 443). This is why SNI was invented, which allows certificates to be bound to a non-specific IP (like 0.0.0.0 or *) and the correct certificate can be determined during the ssl handshake with the browser instead based on the domain name in the request.

If you have an IIS binding that binds https to a specific IP (such as a default website or default ssl binding) then this will take priority over every other https binding that will possibly apply for that IP/port combination, so in other words assuming you only have one IP address attached then that binding will take priority, in which case you need to hunt down the offending binding and remove it, and only ever use IP specific bindings (or non-SNI bindings) if you are absolutely sure you know the implications.

[Stuart88]

@webprofusion-chrisc Thanks, I'll look into this. Must admit, IIS and general web administration is not my strong suit. I tend to just hack away until it works. Time to get my hands dirty and actually figure this stuff out. Thanks for the pointer.

Oh and yes I did mean 2016, ha! Genuine typo, I even specially checked what version I was using before typing it out...!

[webprofusion-chrisc]

No worries, you'll probably find it's the site with chinaglobalconnections https binding that's the culprit and you just need to delete that https binding and re-add it as an SNI enabled https binding with IP address set to 'all unassigned'.