What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

SSL Sensors & Subject Alernative Name(SAN) Certificates

Votes:

0

We've started implementing Subject Alternative Name (SAN) SSL/TLS Certificates in our environment. I suspect the SSL Certificate Sensor isn't currently capable of differentiating the SAN Certificate alternative name from the SAN Certificate's Common Name and is therefore failing the sensor channel's CN check.

Is that a known issue, and if so, I'd like to recommend that it be considered for a road map item in the future.

Image description

Otherwise, maybe you could point out what I might be doing wrong. All other online SSL Checker Websites are reading my common name check correctly.

Example: SAN Cerficiate's CN:

Thank You, Adam

certificate san ssl ssl-certificate subject-alternative-name

Created on May 9, 2016 2:11:47 AM

Last change on May 9, 2016 11:46:38 AM by Luciano Lingnau [Paessler]



Best Answer

Accepted Answer

Votes:

1

Update: Support for Subject Alternative Names as of PRTG 16.4.28

Good news: As of PRTG version 16.4.28 (see version history), which is available now, the SSL Certificate sensor has the option to evaluate Subject Alternative Names (SAN).

  1. Open the sensor settings.
  2. Go to settings section SSL Certificate Specific.
  3. For setting Certificate Name Validation, choose the option Compare and show 'down' status if common name/alternative names and address/SNI do not match to check for the Subject Alternative Name as well.

Created on Nov 30, 2016 4:33:36 PM by Gerald Schoch [Paessler Support]



9 Replies

Votes:

1

Hello Adam,
thank you for your post.

Yes, I'm able to confirm that currently(As of PRTG 16.2.23.3270) the SSL Certificate Sensor when configured to Compare and show 'down' status if common name and address do not match will do exactly what it says, it will compare the device's address (FQDN) to the Common NAME (CN) of the queried certificate.

This means that a sensor deployed on the FQDN api.digicert.com set to perform Certificate Name Validation will go into DOWN as api.digicert.com doesn't match CN = www.digicert.com, even though api.digicert.com may be a valid Subject Alternate Name (SAN) for that Host/Port.

We are evaluating the possibility of changing this behavior in the future.

Best Regards,

Created on May 9, 2016 11:52:51 AM by Luciano Lingnau [Paessler]



Votes:

0

Thanks for confirming that, it's what I'd suspected but it's good to have confirmation. I do hope you'll consider adding the feature to check the possible alternative names at some point in the future.

Thank you again, and kind regards, Adam

Created on May 9, 2016 1:35:16 PM



Accepted Answer

Votes:

1

Update: Support for Subject Alternative Names as of PRTG 16.4.28

Good news: As of PRTG version 16.4.28 (see version history), which is available now, the SSL Certificate sensor has the option to evaluate Subject Alternative Names (SAN).

  1. Open the sensor settings.
  2. Go to settings section SSL Certificate Specific.
  3. For setting Certificate Name Validation, choose the option Compare and show 'down' status if common name/alternative names and address/SNI do not match to check for the Subject Alternative Name as well.

Created on Nov 30, 2016 4:33:36 PM by Gerald Schoch [Paessler Support]



Votes:

0

Hi. My PRTG 17.1.30.1680 SSL sensor doesn't work properly using new feature (check alt subj name). PRTG responds an error Error by lookup value 'Does not match device address' in Common Name Check (OK. Certificate Common Name: ..... but certificate is OK and consist requested SNI in altsubjname extention. What I doing wrong?

Created on May 2, 2017 5:39:55 PM



Votes:

0

Hello almazov , thank you for your reply.

There's a known bug in the current release regarding the SAN and name validation. If you use SNI this option will not work as expected. Without SNI it should work. For instance, the test suggested here works as the SNI setting in the sensor is blank:

While the bug is known, there's no ETA for when it will be fixed yet.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on May 3, 2017 7:28:51 AM by Luciano Lingnau [Paessler]



Votes:

0

Is there already an ETA when this issue will be fixed ?

Best Regards, Marc Meul

Created on Jul 20, 2017 8:44:19 AM



Votes:

0

Hello PerplexMM,
thank you for your reply.

I'm afraid not. I've just checked the task and there's still no ETA for now. Any updates/changes will be available and listed in our release notes.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Jul 20, 2017 12:22:08 PM by Luciano Lingnau [Paessler]



Votes:

0

The SAN extension has been required for some time now. The CN field is insignificant and not worth checking for most cases. Is there still no way to validate that the SAN extension is appropriate for the hostname or service name? I have server certificates that in some cases include the IP address in the SAN extension in addition to the hostname but PRTG still fails the name validation.

I am using option "Compare and show down status if common name (CN)/alternative names (SAN) and address/SNI do not match".

Is there a trick to this or is it still not functioning? Thanks

Created on Oct 4, 2022 5:18:28 AM



Votes:

0

Hi Edix,

I'm afraid that there is no change yet and according to this Knowledge Base thread and tickets raised in our support, almost no request which would result in a high prioritisation of a sensor change, or fix.

I reviewed the internal development cases and we are considering to rewrite the sensor in the future. Please bear with us that I cannot share any ETA yet.

Kind regards,
Felix Saure, Tech Support Team

Created on Oct 4, 2022 5:41:14 AM by Felix Saure [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.