Is there a CRL push infrastructure for Linux that can be hooked into?

Client dev
24

Windows CAPI/schannel (the OS-provided TLS implementation) downloads CRLs in the background, caches them, and periodically refreshes them (this behaviour can be overridden by applications though).

5 Likes
25

Thank you so much for the info. So it does seem then like it's exclusively a Linux issue that it doesn't work properly. Given that most of the backbone of the internet run Linux, that seems a bit scary.

1 Like
26

Linux servers are very common, sure. But TLS Servers are not involved in revocation checking. That's done by TLS Clients. Of course, TLS Clients can also run on Linux. But Windows, Android, and iOS are more popular client systems generally.

I think I'll leave this thread. I leave it to others to help define your scope of work.

3 Likes
27

Funnily enough, the .NET wrapper for schannel (which is used by Powershell, e.g Invoke-WebRequest) does not have revocation checking enabled by default. The user must manually enable it.

the default:
Invoke-WebRequest https://some-site-with-revoked-cert
# Results in no certificate error
configure the ServicePointManager:
[System.Net.ServicePointManager]::CheckCertificateRevocationList = $true
Invoke-WebRequest https://some-site-with-revoked-cert
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
with curl for Windows, revocation checking is enabled out of the box
curl -v https://some-site-with-revoked-cert
curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOKED (0x80092010) - The certificate is revoked.
3 Likes
28

For services that contact each other or do any infrastructure as code, there's going to be a side with a TLS client involved even on a server. That's why this situation is worrying me.

Anyway, as per the thread title I was more hoping to hear of a solution, not to rewrite the entire ecosystem myself. It seems like there is none, however.