I am seeing an odd issue with two of our externally facing systems where access over the web on HTTPS works, and uses the correct COMODO certificates, but internally it is using self-signed certificates.

The command being used to test this is:

openssl s_client -showcerts -connect wiki.domain.com:443

Externally, this returns:

Server certificate
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.domain.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA

Internally (from the local subnet) I see:

Server certificate
subject=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
issuer=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address

Any idea why this would be happening please? I can't figure out what's going on here.

Please ask if you need further details, am happy to provide. Thank you.

  • 1
    Are you sure the internal network is not routed through a proxy? Not that this should happend, but some proxies, (wall garden for ex) redirect the first few requests to an internal router/server. This would automaticaly flag the certificate as invalid as it doesn't match the common name. Aug 24 '16 at 13:01
  • I have an internal nginx server, but would that affect it in this way, as the nginx entry for the wiki.domain.com uses the COMODO certificates?
    – Gary
    Aug 24 '16 at 13:16
  • that depends on the config, I have no idea. Does s_client return a nginx page? Aug 24 '16 at 13:18
  • It doesn't, no. I'll have to look into this some more then and find out what's going on
    – Gary
    Aug 24 '16 at 13:27
  • 1/2: Try with the "-servername" parameter. 2/2: Try with a different software. I prefer testssl.sh for testing LAN sites. Aug 24 '16 at 14:34

Most likely you have a proxy that uses a self signed certificate in order to inspect SSL traffic, some Secure Web Gateway solutions such as McAfee, Cisco, or Websense use a self signed certificate that users install in their computers in order to inspect encrypted traffic for malware prevention, so what you are seeing is the self signed certificate used for the proxy, you should contact the network engineers in your company in order to be sure.

  • Hi Freddy, we have a pfsense set up, do you know if it is possible to get around this on the gateway? Thanks
    – Gary
    Aug 24 '16 at 13:27
  • 1
    it seems that your pfsense might be doing HTTPS Interception using SQUID, you can have a bit more of context of how that works (howtoforge.com/filtering-https-traffic-with-squid), if the proxy is configured in transparent mode there might not be a way to disable ssl inspection just for one site, it is implementation specific but I'm not sure that by putting the url into the whitelist will solve your issue, to check this you would have to bypass your proxy in some way, if the cert looks fine then the responsible is the proxy. Aug 24 '16 at 13:37
  • Hi Freddy, I will provide this information to the network engineer, thank you.
    – Gary
    Aug 24 '16 at 13:48
  • You are quite welcome! Aug 24 '16 at 14:34
  • It seems that SQUID isn't installed on our pfsense box, do you happen to know anything else which could be the cause please? Thanks
    – Gary
    Aug 25 '16 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.