Web browser presented with bogus SSL certificate?

Mark J. Bobak

8/7/23, 7:10 PM

I have what I can only characterize as a very strange problem.

We have customers who, when they visit our website, get an SSL error: ERR_CERTIFICATE_AUTHORITY_NOT_VALID

Upon closer inspection, the certificate presented to their browser is not our certificate. Our certificate is issued by GoDaddy, and is wildcard cert. The cert visible in the user's browser when this error occurs is a single website cert and is issued by Cisco and is only valid for 5 days. We don't even have any Cisco devices of any kind, nor have we ever purchased an SSL cert from them.

Also, this is not happening to all customers, only to some. The problem is occurring with some people who are working in the office, and some who are working from home. Further, the problem users seem to originate in a specific region.

Finally, this problem is not reproducible by us. It's only happening to some of our customers.

Help?

I have no idea what's going on here. Is there a firewall or VPM device that is generating this rogue cert? (Presumably a Cisco device?)

0 + 0

ssl

ssl-certificate

vidarlo

8/7/23, 7:12 PM

The short validity combined with the fact that it mentions cisco would make me guess it's a ssl intercepting proxy that's misconfigured or the devices that see this warning does not have the CA cert installed. It's probably a problem in their organization.

Mark J. Bobak

8/7/23, 7:30 PM

That's sort of what I was thinking, but you said it more clearly.... :-) This is going to be difficult to trace, since I have no access to their network.

Mark J. Bobak

8/7/23, 7:35 PM

Another thought: I'm no SSL expert, by any means, but I thought if I owned the domain, only I could issue SSL certs for my domain? I have a \*.example.com cert that *should* be used, but their device is issuing a specific cert, host1.example.com, with issuer Cisco. How is that even possible?

Steffen Ullrich

8/7/23, 7:40 PM

@MarkJ.Bobak: Everybody can issue for any domain if they use their own CA instead of publicly trusted CA like Let's Encrypt. Only, these certificates will not be trusted by the browsers unless their own CA is explicitly added as trusted. In corporate environments the CA for the SSL intercepting proxy is usually automatically added to the managed systems. Either this is failing or your users use their own device (BYOD) without the additional trusted CA in the company network. In any case, there is nothing you can do, it is a issue with the client and/or client network.

Appleoddity

8/7/23, 7:44 PM

The end user is behind a proxy or filter. It is intercepting the connection and presenting its own certificate in place of yours. It is intercepting the connection to either block it, or to perform deep packet inspection (by decrypting the traffic). The end user device doesn’t trust the certificate because whoever manages the proxy/filter hasn’t set it up right. Anybody can create a certificate with your domain name. But not anybody can have it signed by a TRUSTED Certificate Authority. Therefore, they have to place their self-signed CA in the device’s trusted root store.

Mark J. Bobak

8/7/23, 9:03 PM

Thanks Steffen, thanks Appleoddity, that makes perfect sense, and pretty much aligns w/ what I suspected, though I didn't express it that clearly. Thanks!