Windows Server 2016 Essentials certificate problem on xxx.remotewebaccess.com

Question

I had to renew my certificate this month and I was able to release and renew the domain without any problems. However when I tried to access the server from my iPhone using the SSTP Connect VPN app I received the following error message:

DANGEROUS!

TLS verification on the server certificate (xxx.remotewebaccess.com) has failed due to the following error. As such, the identity of the server can't be verified at the moment.

Certificate 2 "GoDaddy TLS Root CA - R1" has errors: Root is not trusted; This may indicate a server misconfiguration or an ongoing MITM attack. Do you want to trust the server certificate and continue? Choose Cancel if you are unsure.

Options given were: Continue, Save and Continue or Cancel

If I choose Continue I get "Connection Failed. Connection aborted by the server"

If I try to connect from a Windows PC then it appears to connect but then is immediately disconnected by the server.

When I try to access https://xxx.remotewebaccess.com from Safari on the iPhone I it says the certificate is not valid or not trusted. I can however ignore the the problem and log in to the site.

When I check the certificate it shows the Issuer as:

CN = GoDaddy TLS Intermediate CA DV - R1v1

O = GoDaddy.com

C = US

I'm not sure what it used to be when it worked last month as I deleted the expired certificates but it wasn't " GoDaddy TLS Intermediate CA DV - R1v1" which I find curious to say the least.

Has anyone else run into this or know how to fix it?

Answer 1

Install GoDaddy’s matching complete/alternate certificate chain on the Essentials server so the renewed certificate can chain through a root trusted by the affected clients, then verify externally that IIS is actually sending that intermediate chain.

The new issuer, GoDaddy TLS Intermediate CA DV - R1v1, is consistent with GoDaddy’s transition to the R1 hierarchy ^1^. The iPhone message specifically indicates that its chain terminates at an untrusted GoDaddy TLS Root CA - R1; accepting that warning is not a safe or permanent fix.

Install the complete or alternate GoDaddy chain

1. Back up the renewed certificate and private key before changing certificate stores or bindings.
2. Obtain the complete bundle or alternate/cross-signed chain that GoDaddy specifies for this exact R1v1 leaf certificate. Do not substitute similarly named certificates from another hierarchy. GoDaddy documents using the complete bundle or alternate chain for an untrusted-chain error ^2^.
3. On the server, run certlm.msc.
4. Import the supplied intermediate CA certificate(s) into: Certificates (Local Computer) → Intermediate Certification Authorities → Certificates.
5. Import a root into Trusted Root Certification Authorities only if it is explicitly part of GoDaddy’s verified bundle and its issuer and thumbprint have been checked. Microsoft advises against importing certificates into Trusted Root as a routine troubleshooting measure ^3^.
6. Leave the renewed xxx.remotewebaccess.com certificate, including its private key, in: Certificates (Local Computer) → Personal → Certificates.
7. Restart IIS and the affected Remote Access service so they reload their TLS certificate state. Services that retain TLS sessions or certificate caches may need restarting after a chain update ^4^.

Importing the new self-signed R1 root only on the server does not make an iPhone or remote Windows PC trust it. The interoperability fix is for the server to present the correct intermediate or alternate chain that leads to a root already trusted by those clients.

Verify what clients actually receive

Export the renewed leaf certificate without its private key, then validate it locally:

mkdir C:\Temp\CertCheck
certutil -urlfetch -verify C:\Temp\CertCheck\remotewebaccess.cer ^
  > C:\Temp\CertCheck\verify.txt
notepad C:\Temp\CertCheck\verify.txt

Check the output for the selected chain, missing issuer certificates, AIA/CDP retrieval errors, and the final trust result. Microsoft documents certutil -urlfetch -verify for chain and retrieval testing ^5^.

A successful server-side certutil result is not sufficient by itself: Windows may build the chain from certificates installed locally even when IIS does not transmit the required intermediate. Retest https://xxx.remotewebaccess.com from the affected iPhone over cellular or another external network. The expected result is:

• Safari reports no certificate warning.
• The chain contains the xxx.remotewebaccess.com leaf and intended GoDaddy intermediate.
• The chain terminates at a root trusted by iOS.

Test SSTP only after HTTPS validates without bypassing the warning.

If HTTPS is trusted but SSTP still disconnects

That separates the original chain problem from a possible stale SSTP certificate binding or private-key problem.

1. Confirm the HTTP.sys binding references the renewed certificate’s thumbprint:

netsh http show ssl

For the relevant HTTPS listener, compare Certificate Hash with the renewed certificate’s thumbprint under certlm.msc → Personal → Certificates. Microsoft documents that a missing hash or all-zero application ID indicates a broken HTTP.sys SSL listener configuration ^6^.

Do not delete and recreate the binding manually unless its ownership and application ID are known; the Essentials Anywhere Access configuration can manage multiple related bindings.

2. Open Event Viewer → Windows Logs → System and check events from Schannel, RemoteAccess, and SstpSvc at the connection time.
3. Only if those events report private-key acquisition, logon-session, or certificate-configuration errors:
   • Open certlm.msc.
   • Go to Personal → Certificates.
   • Confirm the renewed certificate says that a corresponding private key is present.
   • Right-click it → All Tasks → Manage Private Keys.
   • Ensure SYSTEM has Read permission.

This permission check applies specifically when SSTP cannot use an otherwise valid certificate under the system account ^7^.

If the alternate chain is unavailable through the managed remotewebaccess.com renewal process, escalate through Microsoft/GoDaddy support for the managed personalized domain rather than replacing the certificate with an unrelated manually issued one.

---

References

1. Why is GoDaddy removing ClientAuth EKU and transitioning to the R1 root ...
2. GoDaddy - Fix an untrusted root or certificate chain error
3. Inspect certificates and manage certificate store contents
4. Windows Web Services communication failure saying 503 Service Unavailable - Microsoft Q&A
5. ADFS 2.0 certificate error: An error occurred during an attempt to build the certificate chain
6. Troubleshooting SSL related issues (Server Certificate)
7. The Secure Socket Tunneling Protocol service could not configure the following certificate for use with Internet Protocol version 6 (IPv6). - Microsoft Q&A