[Xymon] xymon checking wrong SSL cert on CNAME

[Roland Rosenfeld]

On Thu, 13 Jun 2024, betsys at well.com wrote:

> We have a website at a third-party  hosting company, where our site
> https://www.example.com <http://www.example.com>   is a cname for
> something.hosting.com  (not the real name)
> 
> We have a LetsEncrypt cert issued for www.example.com
> <http://www.example.com> .

> The cert wasn't updating, but xymon did not alert , because xymon is
> apparently evaluating the CNAME and then checking the cert for hosting.com
> (which has a wildcard cert *.hosting.com)

I cannot believe this.  We also have CNAMEs pointing to hosts and the
cert check works as expected.  Did you check the "sslcert" column?

In this column I see a list of all https checks for this host listing
the request URL (without the IP-pinning, if you did so) with the
certificate subject, issuer and validity start/expire.

> How do we make xymon check the cert for www.example.com, other than
> writing our own script? I think this is a fairly common setup for
> hosted websites
> 
> (for a minute I thought about adding an A record but that would be wrong on
> multiple levels)

> /home/xymon/server/etc/hosts.cfg has 
> 
> x.x.x.x  www.example.com # noconn httpstatus;http://www.example.com/;301;
> https://www.example.com

That's nearly what I'm doing.  The x.x.x.x is irrelevant since you use
noconn.  The https://www.example.com checks this URL and the sslcert
column should show the cert of this URL.

Here's an example I use (a little obfuscated):

1.2.3.4  foobar # noconn httpstatus;http://foobar.example.com;301 \
         httpstatus;http://foobar.example.net;301 \
         https://foobar.example.com=1.2.3.4/login \
         https://foobar.example.net=1.2.3.4/login \
         https://foobar.example.com=1.2.3.10/login \
         https://foobar.example.net=1.2.3.10/login

foobar.example.com and foobar.example.net are both CNAMES to the same
double-A-Record pointing to 1.2.3.4 and 1.2.3.10.

In the sslcert column I see:

SL certificate for https://foobar.example.net/login expires in 323 days

Server certificate:
	subject:/CN=foobar.example.net
	start date: 2024-04-03 00:00:00 GMT
	expire date:2025-05-02 23:59:59 GMT
	key size:2048
	issuer:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL TLS RSA CA G1
	signature algorithm: sha256WithRSAEncryption

green SSL certificate for https://foobar.example.com/login expires in 176 days

Server certificate:
	subject:/CN=foobar.example.com
	start date: 2023-11-06 00:00:00 GMT
	expire date:2024-12-06 23:59:59 GMT
	key size:2048
	issuer:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL TLS RSA CA G1
	signature algorithm: sha256WithRSAEncryption

green SSL certificate for https://foobar.example.net/login expires in 323 days

Server certificate:
	subject:/CN=foobar.example.net
	start date: 2024-04-03 00:00:00 GMT
	expire date:2025-05-02 23:59:59 GMT
	key size:2048
	issuer:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL TLS RSA CA G1
	signature algorithm: sha256WithRSAEncryption

green SSL certificate for https://foobar.example.com/login expires in 176 days

Server certificate:
	subject:/CN=foobar.example.com
	start date: 2023-11-06 00:00:00 GMT
	expire date:2024-12-06 23:59:59 GMT
	key size:2048
	issuer:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL TLS RSA CA G1
	signature algorithm: sha256WithRSAEncryption

(as you can see, the certificates of foobar.example.com and
foobar.example.net have different certificates with different
lifetimes).

They are duplicated, because this is checked for both IPs (so I see,
if only one of the two cluster nodes gets a new cert).

Greetings
Roland