Certificate problems

[Matthew Lynch]

This issue was discussed in a previous post "Frequent captcha, cloudflare blocks and temporary cert problems".  I am starting a new thread because I think the "frequent captcha/cloudlfare blocks" are one issue and the "temporary cert problems" is a separate issue.  This post asks about troubleshooting the temporary cert problems.

I am using MITM transparent proxy e2guardian 5.5.7r.

Frequently but unpredictably I will get a "privacy error" page in Chrome.  Typically, refreshing the browser will fix the problem and allow access to the website without any further errors.  This can lead to problems for embedded software like javascript or other code that is accessed by never pops up its own window that can be refreshed

Inspecting the details of the privacy error shows the Common Name of the certificate is not the domain trying to be access but rather is an ip address.  The SSL error is net::ERR_CERT_COMMON_NAME_INVALID -- presumably because the "common name" is the ip address and not the domain name.

The access.log says 

"2025.09.08 20:18:36","","192.168.1.118","https://212.83.169.215","*DENIED* Failed to negotiate ssl connection to client","","0","0","SSL SITE","1","403","","192.168.1.118","group1","","","-","-",""

I have disabled encrypted client hello in the Chome browser ("Use secure DNS" off) and as a group policy on the computer (adding a registry entry EncryptedClientHelloEnabled = 0).  I have also blocked DoT port 853 at the router level and tried adding a domain list to pi-hole to prevent DoH.  This problem occurs with or without pi hole active.

Google AI says the follow could be the problem.  Is this true?

• Modern browser and RFC compliance: Modern browsers rely on the Subject Alternative Name (SAN) field for certificate validation and generally ignore the Common Name (CN). If E2Guardian is using older OpenSSL libraries or generating certificates incorrectly, it may not include the necessary SANs. This causes a certificate mismatch error, which might display the IP address depending on the certificate generated by the proxy.

I generated my self-signed e2guardian MITM cert several years ago.  Do I need to create a new one now?

[Philip]

Sorry to be so long getting back to you on this.  I have been away.

Google AI says the follow could be the problem.  Is this true?

No, it is not true.  E2g generates a correctly formatted SAN as well as a COMMON_NAME.      

Your self-signed root CA should be OK.   If this was an issue MITM would not work at all.

As you are using transparent MITM,  e2g will attempt to extract the site to connect too from the SNI in the ssl Client_Hello request.  The extracted destination may be a host name or an IP address.  If the extraction fails, e2g will attempt to use the destination IP address (but should log in syslog).

It could be that the client is attempting to use ECH (I have seen this even when ECH is off in browser)

The best way to fault find this would be to use wireshark (or similar) to examine the conversation between client and e2g, so you can see exactly what the client is sending and how e2g is responding.

Regards

Philip

[Matthew Lynch]

I'm still working on this by analyzing Wireshark traffic.  Please forgive any oversights as I am not experienced when it comes to netorking.  I am still not sure what is causing the problem.  But it appears in one example the client hello packet sends a domain name and e2guardian sends back an IP as the common name, so it fails:

Client Hello sends: server_name=www.readinga-z.com

Server Hello certificate downloaded from Wireshark .... 

openssl x509 -text -noout -in cert-stream-760.crt shows:
        Issuer: CN = e2guardian, O = e2guardian, C = US
        Validity
            Not Before: Mar 20 23:51:01 2025 GMT
            Not After : Jul  9 02:30:51 2033 GMT
        Subject: CN = 104.18.33.109
...
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                IP Address:104.18.33.109
 
 it gives the IP in the common name and SAN fields so the client then sends a fail message back to server because the CN/SAN doesn't match the domain in the browser.

Is this a problem with e2guardian sending back the wrong thing or could it be something misconfigured (and if so, what)?

[Matthew Lynch]

I will provide some follow up and a work around solution.  The solution is to fully disable encrypted client hello, and requires two steps

The first step can be done in Chrome using a policy, as outlined at this website:

https://chasersystems.com/blog/disabling-encrypted-clienthello-in-google-chrome-and-why/

In Windows it is done through the registry, in Linux by creating a policy file in a specific folder described in the article.

However, this did not completely eliminate the problem.  It reduced in frequency, and the frequency seemed to vary on different machines, but I would still get ERR_CERT_COMMON_NAME_INVALID due to e2guardian replacing the domain name with IP.  It was intermittent because just by reloading the page, it would not give the error.

I confirmed that ECH was NOT being used on the following websites:

defo.ie

tls-ech.dev

A better check is: https://crypto.cloudflare.com/cdn-cgi/trace

which confirmed  "sni=plaintext" 

However, it appears in Wireshark that some Client Hello streams still contained an "encrypted_client_hello" extension in addition to the plaintext "server_name" extension.  For some (not all) of these, e2guardian did not seem to find the SNI and so returned the IP in the certificate, causing the mismatch error.

Second step: To solve this, I had to disable TLS v1.3 entirely and force Chrome to use TLS v1.2 (in addition to the policy above).

This is done by adding the command line option "--ssl-version-max=tls1.2" to every shortcut to start Chrome.

It appears I am now not getting ERR_CERT_COMMON_NAME_INVALID any more.

You can confirm use of TLS v1.2 on the following website:

https://crypto.cloudflare.com/cdn-cgi/trace

It should say "tls=TLSv1.2"

I'm not sure if this is expected behavior with e2g. I reviewed the code for ConnectionHandler::get_TLS_SNI. I have examples of multiples Client hellos from Wireshark showing both "encrypted_client_hello" extension and "server_name" extension (which appears to be plaintext) and sometimes it returns a domain name and sometimes it returns "" so then the following code gets run to put the IP in the CN/SAN:

            if (!checkme.hasSNI) {
                if (checkme.got_orig_ip) checkme.url = checkme.orig_ip;
...

            }

I don't understand why it sometimes find the SNI and sometimes doesn't.

[Philip Pearce]

Hi Matthew,

 

Thanks for the detailed information you have sent.

 

I have unable  to replicate the SNI issue here on my test rig.    However, it is a basic rig running on VM’s and so the requests are not running over an extensive network.

 

From the symptoms you describe, it seems to me that the problem may be triggered by network congestion causing a delay in getting the full ClientHello header from the client.     I.e. The full CleintHello has not reached the e2g server by the time e2g does the call to peek at it.

 

Can you try replacing the following line in ConnectionHandler:- (around line 3160)

 

            rc = peerconn.readFromSocket(buff2, toread, (MSG_PEEK), 10000);

 

with:

 

            rc = peerconn.readFromSocket(buff2, toread, (MSG_PEEK|MSG_WAITALL), 10000);

 

And see if that fixes the issue?

 

Let me know the result and if it fixes the issue I will post the fix to github.

 

Regards

Philip

 

 

 

--
E2guardian:
https://groups.google.com/d/forum/e2guardian
Github:
https://github.com/e2guardian/e2guardian
Follow us on twitter:
https://twitter.com/e2guardian
---
You received this message because you are subscribed to the Google Groups "e2guardian" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e2guardian+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/e2guardian/6837e9f1-b5eb-4227-b21e-d0009c4f6c00n%40googlegroups.com.

[Matthew Lynch]

This change fixed the issue.

[Philip]

See https://github.com/e2guardian/e2guardian/issues/857