If you already have a certificate for mydomain.com:443, why do you need a different certificate for mydomain.com:222? The certificate does not need to change depending on what port/service will be using it.
If IIS is managing both 443 and 222, I would have imagined CertifyTheWeb’s auto configuration would do it for you, but you can try forcing it with options like the following:
Any website in IIS with mydomain.com in it will get the certificate attached to it regardless of port.
If your 222 site is not managed by IIS, you may need to create a post deployment script that copies the certificate somewhere and restarts your external service.
If your 80/443 site is not managed by CertifyTheWeb but you want 222 managed by it, then maybe you’re running into difficulty getting LetsEncrypt working because HTTP-01 requires usage of port 80. It’s hard to tell without more information.
As @jljtgr says matching on hostname should work if you have an existing working binding on port 222, or Existing binding uses old version of same certificate (assuming you have manually updated the binding in IIS already).
You can verify what the settings change is planning to do using the Preview tab (bindings are at the bottom of the page) as this tells you exactly which bindings it plans to add/update by doing a dry run of the binding process and noting what would get updated.
Tried various options and still getting ’ This site can’t provide a secure connection’
I’m trying to keep everything very very simple so its just 2 directories with the same site in each.
2 IIS ‘sites’ pointing to respective directories.
The test one binding to 18.104.22.168 port 222.
So… your port 222 site is a normal HTTP site, which is why your client would say that it cannot provide a secure connection. Since your production site has a port 80 binding to do the HTTP-01 challenge, your test site does not need a normal HTTP binding at all.
You need to delete the HTTP binding on port 222 and create a new HTTPS (type) binding on 222. In the Add Site Binding page, also select the SSL certificate previously created for your 443 site. This SSL certificate will most likely have “[Certify]” in the name. I would also fill out the Host name to match the 443 site/certificate and check Require Server Name Indication. Considering how many sites you have managed there, it’s probably needed.
Back in CertifyTheWeb, I would suggest trying out the Auto create/update IIS bindings. Using port 222 specifically might make it unable to update your 443 site with the same certificate. The “Existing binding uses old version” should be unnecessary if your Host name fields are correct… but I don’t see it hurting anything.
With those settings, when Certify renews your production certificate, it should also update the hrptradev2 binding as well.
I can’t tell from the screenshot if you are on Server 2008 R2 or not? If you are on server 2012 or higher then read this before creating an IP specific certificate binding: https://medium.com/@webprofusion/troubleshoot-windows-ssl-https-1fa5bcb8ab90
If you are on Server 2008 R2 then there is no SNI and you can only have one cert per IP/port combination which may be why you’re trying to bind to port 222 (as 443 is already taken on that IP).
Manually create the https binding bound to your current certificate in IIS, port 222. If you then look at the ‘Preview’ tab for your certificate in Certify it should say that next time it renews it’s going to update all the correct bindings (including your manually added 222) because by default that’s what Auto deployment mode will do (matching on old certificate).