2

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.)

2

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.

  • 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. – Casey Crookston Sep 11 '18 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. – apocalysque Sep 11 '18 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. – Casey Crookston Sep 11 '18 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 '18 at 1:00
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.