16

We have an IIS ARR server which load balances out to two different individual IIS servers.

The servers in question are our internal Staging servers. Three months ago I created a free Let's Encrypt SSL Cert to use on these servers. As is the case with Let's Encrypt, it expired after 3 months. So today I got around to creating a new cert, and I replaced the old certs on the ARR server and both load balanced servers.

After doing that, and then going back to the site in any browser (including incognito mode), it's still showing the old invalid cert. I even went to the site on laptops that have never been to this site before just to see if the old cert was cached in my browser. Even those laptops loaded the site with the Not Secure warning.

These are the steps I've taken:

On the ARR server:

  • In IIS, on the server, open "Server Certificates"
  • Remove the old cert
  • Import the new cert
  • Verify the new expiry date is now 3 months out
  • IISReset

enter image description here

On the Two Load Balanced Servers:

  • In IIS, on the server, open "Server Certificates"
  • Remove the old cert
  • Import the new cert
  • Verify the new expiry date is now 3 months out
  • On the site, go into Bindings
  • Drill into SSL and verify that the SSL cert is the new one
  • IISReset

enter image description here

Yet despite all traces of the old cert being removed, including deleting the actual file, no matter what I do, it loads in every browser (ie, chrome, ff) on every computer showing the old cert still.

I don't know what else to do.

If this helps:

enter image description here

(I should add... there is a LOT of this exact same question on many different forums. I've read dozens of them. None of them have to lead me to a solution.)

5 Answers 5

10

You need to select the new certificate under the Default website for https 443 port. (bindings)

enter image description here

1
  • 1
    This must be the accepted answer.
    – Denis
    Jul 10, 2022 at 21:31
6

If your load balancer is taking the SSL offload then it will be the device that terminates the SSL connection and performs the handshake. You'll need to make sure the load balancer has the correct certificate.

4
  • Thanks! But I for sure did that. I put the new cert on all three servers. The load balancer (ARR) and the two actual content servers. Sep 11, 2018 at 19:21
  • 1
    On the ARR you might also need to change the certificate for the "site" or whatever they call it. I believe site-specific certificate settings will override server cert settings. I'm sorry I'm not sounding very helpful, I don't have an IIS in front of me right now. Sep 11, 2018 at 19:33
  • I'm not sure I follow. I've dug all through the ARR server in IIS and I'm not seeing a way to assign a cert to a site here. Only on the server level. Sep 11, 2018 at 20:25
  • @CaseyCrookston You might use a tool like Jexus Manager to check certificate mapping, docs.jexusmanager.com/tutorials/https-binding.html
    – Lex Li
    Sep 12, 2018 at 1:00
4

Like a lot of the other posts I read where people were having the same problem, the solution here ended up being (somewhat) unrelated to the install of the new SSL cert.

Short answer: A reboot of all three servers (load balancer and actual content servers) was required. That seemed to finally clear the server's cache of the old cert.

Long answer: One of the IIS content servers (not the ARR load balancing server) seemed to have a bad IP address. Meaning, the static IP address we had given it was apparently being used elsewhere on the network. This was causing the ARR server to only use the other content server. All of this caused weird problems serving the site in general (occasional 502 errors), which I was attributing to the new SSL cert, and it also made it hard to bring the entire site back online after a reboot.

Bottom line.... the install of the new SSL cert was not the real issue. Once we solved the real issue, and after a reboot of all servers, the problem was resolved.

2

The question actually gave me a clue to the required fixed.

When using netsh http show sslcert it actually showed entries for both 0.0.0.0:443 and {machine-ip}:443.

Hunting around (e.g. in Windows Admin Centre, or various other tools) to see which certificate was which (based on the displayed Certificate Hash), then I saw that the certificate bound to 0.0.0.0:443 was the required new one, and the certificate bound to {machine-ip}:443 was the old one.

So the fix, if netsh http show sslcert displays both certs as above, is:

netsh http delete sslcert ipport={machine-ip}:443

where {machine-ip} should be replaced with the actual IP address in question.

This immediately fixed it, and all sites started using the new certificate.

0

This command worked for me. I was struggling from 3-4 days to resolve the issue of Old ssl cert still showing up in browser after installing new.

netsh http delete sslcert ipport={server private-ip}:443

Thanks https://serverfault.com/users/270826/mikebeaton

2
  • This does not really answer the question. If you have a different question, you can ask it by clicking Ask Question. To get notified when this question gets new answers, you can follow this question. Once you have enough reputation, you can also add a bounty to draw more attention to this question. - From Review
    – djdomi
    Feb 27 at 18:49
  • 1
    Hi NikhilKumar - I am glad my answer helped, but you are not supposed to give a separate answer just to say this. You could just say it in a comment below mine, &/or of course up-vote my answer! (Btw I'm sure you already did, so thank you!) :-) If I was you I would maybe delete this separate answer - as @djdomi says, saying that someone else's answer worked without adding anything else is not an answer, by Stack Exchange rules, so someone else might give you drive-by downvotes! :-/
    – MikeBeaton
    Mar 20 at 15:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .