Ask a Question

Mail server certificate revocation check failed when using proxy

0 votes
by (120 points)

Hello. Recently we ran into a problem with Rebex.Net.Ews mail client with http proxy set through Rebex.Net.Ews.Proxy property. It appears that this proxy is not used when server certificate revocation check is performed and connection fails:

2022-02-17 10:33:26.840 DEBUG Ews(1)[1] EWS: Executing Connect method.
2022-02-17 10:33:26.862 DEBUG Ews(1)[1] Info: Culture: en; windows-1252
2022-02-17 10:33:26.864 DEBUG Ews(1)[1] HTTP: Connecting to 'https://xxxx.xx:443'...
2022-02-17 10:33:26.865 DEBUG Ews(1)[1] Info: Assembly: Rebex.Networking R6.1 for .NET 5.0
2022-02-17 10:33:26.865 DEBUG Ews(1)[1] Info: Platform: Windows 10.0.14393 64-bit; CLR: .NET 6.0.2
2022-02-17 10:33:26.865 DEBUG Ews(1)[1] Info: Culture: en; windows-1252
2022-02-17 10:33:26.881 DEBUG Ews(1)[1] Proxy: Resolving 'yyyy.yy'.
2022-02-17 10:33:26.897 DEBUG Ews(1)[1] Proxy: Connecting to HTTP CONNECT proxy at yyyy.yy:8080.
2022-02-17 10:33:26.901 DEBUG Ews(1)[1] Proxy: Connection established.
2022-02-17 10:33:26.909 DEBUG Ews(1)[1] Proxy: Connection initialized successfully.
2022-02-17 10:33:26.987 DEBUG Ews(1)[1] TLS: Using classic TLS core.
2022-02-17 10:33:27.030 DEBUG Ews(1)[1] TLS: Enabled cipher suites: 0x000F3DF7EBE00640.
2022-02-17 10:33:27.105 DEBUG Ews(1)[1] TLS: Applicable cipher suites: 0x000F3DF7EBE00640.
2022-02-17 10:33:27.117 DEBUG Ews(1)[1] TLS: HandshakeMessage:ClientHello was sent.
2022-02-17 10:33:27.151 DEBUG Ews(1)[1] TLS: HandshakeMessage:ServerHello was received.
2022-02-17 10:33:27.153 DEBUG Ews(1)[1] TLS: Negotiating TLS 1.2, RSA with ephemeral ECDH, AES with 256-bit key in GCM mode, AEAD.
2022-02-17 10:33:27.155 DEBUG Ews(1)[1] TLS: The server supports secure renegotiation.
2022-02-17 10:33:27.157 DEBUG Ews(1)[1] TLS: HandshakeMessage:Certificate was received.
2022-02-17 10:33:27.187 DEBUG Ews(1)[1] TLS: HandshakeMessage:ServerKeyExchange was received.
2022-02-17 10:33:27.187 DEBUG Ews(1)[1] TLS: HandshakeMessage:ServerHelloDone was received.
2022-02-17 10:33:27.196 DEBUG Ews(1)[1] TLS: Verifying server certificate ('CN=*.xxxx.xx').
2022-02-17 10:34:42.284 DEBUG Ews(1)[1] TLS: Certificate verification status: UnknownRev, OfflineRev (0x01000040)
2022-02-17 10:34:42.286 DEBUG Ews(1)[1] TLS: Certificate verification result: RevocationCheckFailed
2022-02-17 10:34:42.298 DEBUG Ews(1)[1] TLS: Error while processing TLS packet: Rebex.Net.TlsException: Unable to perform revocation check of the server certificate.
   at kautv.zjhol.oluuc(String p0, String p1, CertificateChain p2)
   at kautv.zjhol.ffyfp(Byte[] p0, Int32 p1, Int32 p2, nufvk p3)
   at kautv.zjhol.hfrvv(Byte[] p0, Int32 p1, Int32 p2)
   at kautv.xvxgb.vrsuc(Byte[] p0, Int32 p1, Int32 p2)
   at kautv.xvxgb.wwkxd()
2022-02-17 10:34:42.302 DEBUG Ews(1)[1] TLS: Fatal Alert:CertificateUnknown was sent.
2022-02-17 10:34:42.306 ERROR Ews(1)[1] EWS: Connect failed: Rebex.Net.TlsException: Unable to perform revocation check of the server certificate.
 ---> Rebex.Net.TlsException: Unable to perform revocation check of the server certificate.
   at kautv.zjhol.oluuc(String p0, String p1, CertificateChain p2)
   at kautv.zjhol.ffyfp(Byte[] p0, Int32 p1, Int32 p2, nufvk p3)
   at kautv.zjhol.hfrvv(Byte[] p0, Int32 p1, Int32 p2)
   at kautv.xvxgb.vrsuc(Byte[] p0, Int32 p1, Int32 p2)
   at kautv.xvxgb.wwkxd()

When I set up proxy in the OS, certificate revocation check passes and client connetcts to server. Unfortunately we cannot set up proxy in the OS for the production environment due to security policy. Is it possible to set up proxy in Rebex library so it is used also for revocation check?

1 Answer

0 votes
by (148k points)

This is actually a very interesting problem. Rebex libraries use the specified proxy for their own communication. However, for X.509 certificate validation, we use the API supplied by .NET, which in turn uses CryptoAPI on Windows. And as a matter of fact, Windows CryptoAPI does not pay any attention to Rebex proxy settings.

In other words, we use the OS infrastructure for certificate validation (CryptoAPI on Windows, OpenSSL on Linux, ...), and its communication is beyond our control.

How to resolve the problem? There are several possible solutions:

1) Configure Windows to use the same proxy for it's revocation checking. We have not tried this ourselves, but it looks like it's possible.

2) Skip certificate revocation check. Although this is strongly discouraged in general, it can still be a useful solution in scenarios where the application can simply be stopped and upgraded in the unfortunate case where a target server certificate is revoked. Basically, the application could either keep its own whitelist or blacklist of certificates.

3) Instead of using the OS infrastructure for certificate revocation checking, use a custom certificate engine. We currently only provide a custom certificate validation engine for .NET Compact Framework, but repurposing its certificate revocation checking part on .NET 4/5/6 should be quite straightforward, and we already planned to do this in the following months. So if you consider this to be the best solution, please let me know, and we'll keep you updated!

...