Certificate problems

4 views
Skip to first unread message

Matthew Lynch

unread,
Sep 8, 2025, 8:52:21 PM (4 days ago) Sep 8
to e2guardian
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?


Reply all
Reply to author
Forward
0 new messages