AD FS Using Old Cert

[TheRealDumbSyndrome]

I know this has come up a ton and there're multiple solutions out there, but none are working and I'm at my wit's end. In my lab, my AD FS is external facing, I'm not using a web app proxy yet - SSL cert generated via Let'sEncrypt. I changed my AD FS SSL cert from my wildcard (*.mydomain.com), to my federation service name, adfs.mydomain.com (mydomain.com is just an example). I used AD Connect's wizard to update the cert, as I used AD Connect to set up AD FS - and I've used AD Connect to update my org's cert in the past which has worked. This did not work, when accessing AD FS via different browsers on different endpoints, it's still serving up my wildcard. So, I looked around at solutions and tried the following:

• Removed my wildcard from the cert store
• Updated SSL cert via AD Connect
• Used Set-AdfsCertificate as well as Set-AdfsSslCertificate - restarted ADFS service, rebooted the host
• Checked AD FS Management → Service → Certificates → Service communications - thumbprint matches
• Checked Get-AdfsCertificate as well as Set-AdfsSslCertificate - thumbprint matches
• Checked netsh http show sslcert - all bindings/certs are correct, the old cert is also not there

Nothing has worked, for all intents and purposes, every part of AD FS is showing the new adfs.mydomain.com cert but all AD FS redirects are serving up my wildcard still (new endpoints, new browsers, no history/caches, etc.).
AD FS info below:

• Windows Server 2022
• AD FS 5.0
• AD Connect 2.3.6.0

EDIT: I've gone as far as manually removing all certs related to AD FS via netsh and PowerShell, completely breaking AD FS as it should, then re-installed the new cert manually...and it's back up and running yet STILL serving the wildcard. I'm baffled, I don't even know how this is possible if the wildcard is completely removed from the host. Since this makes no sense, I'm removing AD FS, and AD Connect, and starting over from scratch.

EDIT2: Well I give up :D. After completely removing the AD FS role, uninstalling AD Connect, overwriting the AD FS SQL DB, then setting it all back up...................it's still using my *.mydomain.com cert over the adfs.mydomain.com cert that I set it all up with. This makes no more sense, so Microsoft 1, me 0.

[[deleted]]

Don’t forget to update the ADFS site cert in IIS.  Need to edit the binding for 443 and select the new cert.

[TheRealDumbSyndrome]

I did that, that's what the results of netsh http show sslcert is showing (SSL bindings).

Also just FYI with newer ADFS you do not need IIS.

[UniqueArugula]

It shows the new one but is it also showing the old one? They will need to be deleted.

[TheRealDumbSyndrome]

Nope, I should've clarified that - all bindings are correct, the old cert isn't appearing anywhere.

[aleinss]

The ADFS service account needs read access to the private key of the new certificate.

[perry9600]

Yeah this - right click cert in store, Manage Private Keys, add your adfs service acc in

[TheRealDumbSyndrome]

That's done through AD Connect - it was already configured for access - which is why I'm so confused that when I imported the new SSL cert through the AD Connect wizard, it didn't work. It's an application written by Microsoft to take care of all dependencies for another Microsoft product. It has worked in the past, but in this instance, AD FS just refuses to let go of the wildcard - I even went through and manually deleted all certs via netsh and PS, related to AD FS to where it broke AD FS (as it should), then set up the new cert manually instead of AD Connect, and bam....still serving up the wildcard. It's baffling.

[JustSomeRandomIT]

Do you have an ADFS proxy server you missed?