Certificate Authentication from untrusted IP address

Question

When I launch my Windows, certificate revocation checks are performed. These occur once when explorer.exe is launched then periodically, every 40 minutes approximately, to 5 IPs. Most of these target Microsoft, Google or Akamai hosts usually geolocated in the Netherlands and US. Disconcerting however is the call to crl.microsoft.com which resolves at an IP controlled by my ISP. I do not use my ISP's DNS and apply a third party DNS ([email protected]) at the OS level using Windows Internet Options.

According to the DNS reply, the host names resolve as follows: CNAME crl.microsoft.com -> ms.akadns.net -> a1363.dscg.akamai.net -> Address 62...*** (ASN: 5089).

But this IP address is registered to my ISP, not Akamai or Microsoft. I don't have any reason to believe my ISP is partnered with Akamai or Microsoft.

After, a Certificate Revocation List is obtained from my ISP's "crl.microsoft.com" address.

When doing a domain-name look-up elsewhere ms.akadns.net resolves to other subhost names and addresses, so the problem is occurring at the ms.akadns.net > a1363.dscg.akamai.net translation step.

a1363.dscg.akamai.net fails to resolve to anything when looked up directly.

My system is clean and I don't use any ISP software. My (ISP-locked) modem is the only ISP hardware on my network.

A very similar problem is described here but I'm not in Romania. The novice user "solves" their problem by disabling the "check for certificate revocation" options on their system.

I was wondering whether somebody could explain what I should do next to gauge the extent of the problem. I would like to cross reference the certificates that I'm getting from the untrusted address against what they should be.

Edit: So other people can find this issue. The outgoing connections are made Svchost.exe using the CryptSvc and DNScache service. Requests to certificating servers are made using the Microsoft-CryptoAPI header.

Answer 1

Obviously Microsoft is using the services of Akamai to direct clients who are asking for crl.microsoft.com somewhere. The whole purpose of the services which Akamai is offering is to load balance traffic on the Internet as intelligently as possible. This is what Akamai's customers (both ISPs as well as content providers) are paying for.

So simply speaking, is works the same way as 8.8.8.8 (Google DNS), which is by no means one single DNS server machine on whole planet earth, but it is a mechanism (IP anycast to be exact) which translates to: Ask the server which is providing Google DNS which is closeby as in the definition of your ISP.

Same thing here for CRL instead of DNS. There is not the Microsoft CRL server, there is for sure one authoritative certificate revovation list maintained by Microsoft, but it will be distributed by replicating over a number of machines throughout the Internet.

You are surprised that the final server you end up connecting to is located in your ISPs ASN; but just that makes a lot of sense for your ISP, Microsoft and Akamai. I have no idea how big or small your ISP is, but by setting it up that way your ISP does not have to load his phyiscal lines to other ASNs with traffic to crl.microsoft.com, but instead they run a mirror on their own network. This is common with a lot of services.

If you are asking if you should trust that mechanism: You are basically trusting your ISP and Akamai here or not. Of course, it would be possible that for whatever reason the CRL mirror at your ISP's network is not updated in time and you will miss a certificate revocation or your ISP might theoretically even manipulate it by purpose.

In case you want to mitigate that risk, find out if you can point your browser to any other CRL service or override crl.microsoft.com in your DNS resolution mechanism (for example through the hosts file; see https://en.wikipedia.org/wiki/Hosts_(file)) not to be a CNAME to ms.akadns.net but to a different service with appears more trustworthy to you.

Answer 2

I was able to read the crls with certutil. The checksum and list records obtained are the same as those from other networks and the Microsoft repository. It is really only an ISP cache as TorstenS kindly explained.

Here is the same phenomenon. Akamai points to an Embarq ISP controlled server.