Forum Discussion

Gernot_Meyer's avatar
Gernot_Meyer
Copper Contributor
Jul 30, 2026

Windows integrated CA - Certificates are not usable for any browser NET::ERR_CERT_INVALID

Hi all,

a Windows integrated CA on Windows Server 2025.

I have published web server certs on IIS (should be for Exchange on prem). Did this couple of times.

But all Certificates released by this CA are not usable for any browser: NET::ERR_CERT_INVALID.

Tried with different browser and different server. Cert is valid surely. root cert also in place.

error detail: "normally uses encryption to protect your information. When Google Chrome tried to connect to localhost this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be localhost, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.

You cannot visit localhost right now because the website sent scrambled credentials that Google Chrome cannot process. Network errors and attacks are usually temporary, so this page will probably work later."

Any hints what is wrong?

Thanks for hints 

Gernot

2 Replies

  • Gernot_Meyer's avatar
    Gernot_Meyer
    Copper Contributor

    Hi,

    thanks for quick answer. Surely I tried with severname instead of localhost. But same result. 

    I included fqdn also. But also for localhost you should normally be able to continue showing content in browser after excepting browser warning. 

    certutil I checked and did not get any visible error.

    I also created a new web site on exchange server on unused port just for checking. So it has nothing to do with exchange. 

    Changing the certificate to a self signed cert created by the server itself, web pages are running fine (after excepting warning). So NET::ERR_CERT_INVALID error has something to do with my domain CA. I also created a lets encrypt that works fine.

    More help is needed.

  • The error appears while Chrome connects to localhost, so first check whether the certificate covers localhost or the Exchange name clients should use. A trusted root alone is insufficient: the served certificate must be valid, chain to a trusted CA, include Server Authentication, match the requested DNS name, have a private key, and be bound to HTTPS. Open the browser certificate details and record the subject, SANs, issuer, thumbprint, and exact error. Test with the Exchange FQDN instead of localhost. On the server, run certutil -verify -urlfetch against an exported certificate and netsh http show sslcert; compare the thumbprint with the IIS binding. For Exchange, confirm the certificate is assigned to IIS using Get-ExchangeCertificate, and enable the intended certificate for IIS if required. If the SAN lacks mail, autodiscover, or the tested FQDN, issue a new Web Server certificate with those names rather than bypassing the warning.