1

I have a certificate issued by lets encrypt and one of the certificate in the path has this information:

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://x1.c.lencr.org/

On the client machine (that runs in the highly restrictive environment) I can open my URL in firefox/postman, but not in Chrome or dotnet code. Chrome either times out or show a weird error that time is ahead (which is not correct).

After running some tests with wireshark/tcpview it seems that when the client tries to access my server it does an additional TCP connections to various IPs that seem to differ each time (they fail due to firewall). I have a test client that does nothing else but one https call and I see more than one IP in the TCP connection list (with all but my server itself failing because of firewall). This is a screenshot:

enter image description here

In dotnet the error for TLS validation that I get is called RemoteCertificateChainErrors.

I don't know for sure, but my guess is that it tries to check the revocation list for the certificate that cannot be reached and thus fails. Firefox and postman perhaps just do not do the check or ignore if the revocation list url fails.

I am wondering if this explanation is plausible and why there are different IP's that I see all the time (perhaps some CRL load balancing?) and more importantly if there are some good ways of solving this.

We can't start opening these IP's as this can probably change randomly and is not a good idea to be dependent upon

Possible solutions that I see:

  • Open for all traffic (can be hard to push through)
  • Have some other certificate that does not have CRL (which will take time and effort)

P.S. I have additionally accepted all certificates in my dotnet code as a test: it succeeds after a timeout.

9
  • You very vague describe what you see , i.e. "additional call to various IPs that seem to differ each time". It is impossible to deduct from this what is actually happening. I very much doubt that this has anything to do with CRL because browsers usually don't check the CRL in the first place - they use instead other mechanisms for revocation checks. Commented Oct 25, 2021 at 13:14
  • There is unfortunately nothing much I have figured out, since all these calls are blocked, so it's only TCP "SYN sent" Commented Oct 25, 2021 at 13:18
  • I have also added more information on that ignoring certificate validation errors allows the request to come through after a while (~ 30 - 60 seconds) Commented Oct 25, 2021 at 13:22
  • 2
    since in this case no revocation checks should be attempted in the first place -- actually revchecks are done. In .NET, you can pass a custom delegate with your own certificate validation logic (and ignore any errors for testing). However, this delegate is called only when .NET performs its own chain building and validation.
    – Crypt32
    Commented Oct 25, 2021 at 14:45
  • 2
    x1.c.lencr.org CNAMEs to (edgekey and) akamai, so yes you will see lots of different IPaddrs for it because akamai runs huge numbers of servers in almost every imaginable location. IME Firefox does OCSP (not CRL) for leaf (unless stapled, presumably), and nothing visible for intermediate (which you're looking at). I've seen claims they have hardcoded CA revocations, which could be good enough since revoking a CA, unlike a leaf/subscriber/server, is very rare, and Firefox usually autoupdates every week or so. Commented Oct 26, 2021 at 2:17

1 Answer 1

1

It appears that the reason TLS failed is that the machine was an older Windows machine that did not have the latest ISRG Root X1 certificate for lets encrypt. After installing it the connection started working.

The connectivity issue is still relevant though, and thanks to @dave_thompson_085 we figured out that this was an OCSP call that failed. The fact that it fails lead to delays in connection:

  • Firefox: 2 seconds
  • Chrome: 5 seconds
  • Dotnet: no delay (or too little to notice)

So it is apparently dependent on the application what they chose to do when OCSP cannot be reached. All tested applications actually ignore it interestingly enough, but some chose to wait before ignoring.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .