13

Based on information received from the network team. I have determined that the issue most likely rests with the application servers on the WAN.

  1. After replacing the certificate, I ran the PowerShell command Set-AdfsSslCertificate –Thumbprint XXXX (this command sets the thumbprint of the new certificate)
  2. After running the above command, run the command Get-AdfsSslCertificate This command confirms the correct certificate thumbprint is set.
  3. The only other task that may need to be completed would be to set the permissions on the service account. From my research, this looks good.
  4. why the error below referencing 0.0.0.0:443 is being called?

Server and version Windows Server 2012 R2 ADFS 3.0

Issue: After replacement of the certificate and performing the required steps, the QA system fails to function. Errors are being generated in the logs.

Application server logs: An error occurred while using SSL configuration for endpoint 0.0.0.0:443. The error status code is contained within the returned data. Error code 15021

Web Application Proxy logs: Web application proxy service fails to start

The Web Application Proxy Service: service terminated with the following error: A connection with the server could not be established. Error code 7023

lync sahni
  • 151
  • 1
  • 1
  • 5
  • Can you please elaborate on the overall use case here? How are the application server, proxy, and network utilized? What is the expected result? – Mike B Mar 14 '15 at 19:20

3 Answers3

14

First run CMD as Admin

netsh http show sslcert

look for certificates that are dead or the below example Get rid of them by using:

netsh http delete sslcert ipport=0.0.0.0:443

then you should be good.

Mike Caldera
  • 151
  • 1
  • 3
  • 1
    if your list uses Hostname:Port, as in my case, you can use that instead of ipport, as [in this question](https://stackoverflow.com/questions/34029831/argument-not-valid-for-hostnameport-in-netsh-http-delete-sslcert). Just replace **ipport** with **hostnameport** – simonpa71 Dec 09 '20 at 15:27
9
  1. Goto bindings of your IIS website, check if you have a valid cert selected for 443 port.
  2. If you already have, check validity of that cert if already exhausted. Try changing cert to see if its corrupted.
Jakuje
  • 9,145
  • 2
  • 40
  • 44
dev4u
  • 91
  • 1
  • 2
  • Checking bindings in the IIS MMC won't show you *ALL* SSL bindings (e.g. SSTP VPN). Netsh is the way to go as per Mike Caldera's answer. – Thomas Dec 05 '18 at 19:03
1

Run the following command in an elevated command prompt and examine the config on AD FS side.

netsh http sh sslcert

You will see several endpoints and the certs associated with each. AD FS uses name based bindings so wouldn't create one for 0.0.0.0:443 by default. Unless you have IIS or have been doing your own bindings for http.sys they wouldn't just appear there.

I expect you have an old cert referenced in 0.0.0.0:443 . That's a guess based on the data available.

You should take a network trace and see on WAP service startup whether TLS session is established successfully to AD FS.

maweeras
  • 2,674
  • 2
  • 16
  • 23