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