Identrust.com CRL server not responding, connection error in Edge browser

Issuance Tech
1

Suddenly, my website (as well as this forum and any other Let’sEncrypt-protected site) isn’t working in the Edge browser.

Further investigation shows that the Edge browser is trying to check the CRL and is getting a connection timeout on identrust.com CRL and OCSP URLs:

http://crl.identrust.com/DSTROOTCAX3CRL.crl

http://isrg.trustid.ocsp.identrust.com/MFEwTzBNMEswSTAJBgUrDgMCGgUABBRv9GhNQxLSSGKBnMArPUcsHYovpgQUxKexpHsscfrb4UuQdf%2FEFWCFiRACEAoBQUIAAAFThXNqC4Xspwg%3D

etc.

>wget http://crl.identrust.com/DSTROOTCAX3CRL.crl
--2016-10-25 19:49:03--  http://crl.identrust.com/DSTROOTCAX3CRL.crl
Resolving crl.identrust.com (crl.identrust.com)... 192.35.177.64
Connecting to crl.identrust.com (crl.identrust.com)|192.35.177.64|:80... failed: Connection timed out.

Anyone have the same issue?

www.identrust.com is working fine.

2

No issues with those links here. Could you run traceroute crl.identrust.com? This would show where exactly the connection is failing. Odds are, this is a temporary network glitch somewhere between your ISP and IdenTrust’s ISP.

3

This is going on since yesterday (more than a day already).

c:\>tracert crl.identrust.com

Tracing route to apps.digsigtrust.com [192.35.177.64]
over a maximum of 30 hops:

  1     3 ms     1 ms     2 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3    13 ms    12 ms    13 ms  vnn-rc0001-cr101-xe-1-0-2-0.core.as9143.net [213.51.188.17]
  4     *        *        *     Request timed out.
  5    16 ms    20 ms    15 ms  fr-par02b-rd1-xe-3-1-3-0.aorta.net [84.116.134.54]
  6    17 ms    15 ms    30 ms  xe-0-1-0.cir1.amsterdam2-nh.nl.xo.net [80.249.209.200]
  7   168 ms   167 ms   167 ms  te0-3-4-0.rar3.washington-dc.us.xo.net [207.88.13.198]
  8   164 ms   197 ms   172 ms  207.88.12.99.ptr.us.xo.net [207.88.12.99]
  9   160 ms   165 ms   158 ms  207.88.12.132.ptr.us.xo.net [207.88.12.132]
 10   166 ms   172 ms   167 ms  207.88.12.215.ptr.us.xo.net [207.88.12.215]
 11   167 ms   192 ms   165 ms  207.88.12.212.ptr.us.xo.net [207.88.12.212]
 12   163 ms   185 ms   175 ms  207.88.12.165.ptr.us.xo.net [207.88.12.165]
 13   166 ms   164 ms   167 ms  207.88.12.188.ptr.us.xo.net [207.88.12.188]
 14   164 ms   185 ms   203 ms  207.88.12.191.ptr.us.xo.net [207.88.12.191]
 15   168 ms   202 ms   203 ms  216.156.16.25.ptr.us.xo.net [216.156.16.25]
 16   165 ms   197 ms   202 ms  ip65-46-60-234.z60-46-65.customer.algx.net [65.46.60.234]
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26  ip65-46-60-234.z60-46-65.customer.algx.net [65.46.60.234]  reports: Destination net unreachable.

That’s from the Netherlands.

And the same result from a server in the U.S.:

$ traceroute -q1 crl.identrust.com
traceroute to crl.identrust.com (192.35.177.64), 30 hops max, 60 byte packets
 1  router1-nac.linode.com (207.99.1.13)  0.678 ms
 2  173.255.239.4 (173.255.239.4)  1.279 ms
 3  207.99.112.129 (207.99.112.129)  2.144 ms
 4  0.e1-2.tbr2.ewr.nac.net (209.123.10.113)  0.927 ms
 5  ae1-32.nyc41.ip4.gtt.net (173.205.45.185)  0.896 ms
 6  ae1-32.nyc41.ip4.gtt.net (173.205.45.185)  0.882 ms
 7  xe-1-3-3.nyc38.ip4.gtt.net (89.149.134.118)  1.348 ms
 8  207.88.13.34.ptr.us.xo.net (207.88.13.34)  70.397 ms
 9  207.88.13.34.ptr.us.xo.net (207.88.13.34)  70.409 ms
10  207.88.12.218.ptr.us.xo.net (207.88.12.218)  83.331 ms
11  207.88.12.218.ptr.us.xo.net (207.88.12.218)  83.356 ms
12  te-4-1-0.rar3.denver-co.us.xo.net (207.88.12.22)  63.044 ms
13  207.88.12.122.ptr.us.xo.net (207.88.12.122)  61.409 ms
14  207.88.12.122.ptr.us.xo.net (207.88.12.122)  61.469 ms
15  216.156.16.25.ptr.us.xo.net (216.156.16.25)  62.212 ms
16  ip65-46-60-234.z60-46-65.customer.algx.net (65.46.60.234)  62.998 ms
17  *
18  *
19  *
20  *
21  *
22  *
23  *
24  *
25  *
26  *
27  *
28  *
29  *
30  *
$
4

Someone on the #letsencrypt IRC channel just got this error from SSL Labs:

CRL ERROR: Processing failed: Read timed out [http://crl.identrust.com/DSTROOTCAX3CRL.crl]

But the test has been re-run again and doesn't show any errors.

For myself right now, from a few locations in the US, downloading the CRL takes a few seconds but works. From Atlanta and Orlando, well, curl has been trying to connect for over a minute.

Traceroute is similar to the one above: [mtr] f577d9a6 not found -- Usage: [-4/--inet] [-6/--inet6] [-b/--show-ips] [-B NUM/--bitpattern NUM] [-c COUNT/--report-cycles COUNT] [-e/--mpls] [-f NUM/--first-ttl NUM] [-i SECONDS/--interval SECONDS] [-m NUM/--max-ttl NUM] [-n/--no-dns] [-o ORDER/--order ORDER] [-u/--udp] [-v/--version] [-y NUM/--ipinfo NUM] [-z/--aslookup] HOSTNAME -- see https://mtr-atlanta.mn0.us/

It's about the same from locations that work too, e.g.: [mtr] 38a1fe5a not found -- Usage: [-4/--inet] [-6/--inet6] [-b/--show-ips] [-B NUM/--bitpattern NUM] [-c COUNT/--report-cycles COUNT] [-e/--mpls] [-f NUM/--first-ttl NUM] [-i SECONDS/--interval SECONDS] [-m NUM/--max-ttl NUM] [-n/--no-dns] [-o ORDER/--order ORDER] [-u/--udp] [-v/--version] [-y NUM/--ipinfo NUM] [-z/--aslookup] HOSTNAME -- see https://mtr-dallas.mn0.us/

Edit: Atlanta and Orlando both timed out after two minutes. I tried again and they both worked in about 3 seconds.

Edit: Trying Atlanta and Orlando again, sometimes it works after a few seconds, sometimes it doesn't.

5

Thanks for bringing this to our attention. We’re working on contacting the right folks at Identrust to look into this. I’ll update this thread once we know more.

2 Likes
6

Identrust has said there was a period of heavy traffic that may have affected their CRL distribution but believe it was transient.

Are you folks still experiencing issues?

7

I don’t want to make too many requests and overload them again, but right now it seems it takes ~2 seconds and doesn’t fail.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.