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.
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
Article Comments
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
May, 2016 - Permalink
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).
- Open the sensor settings.
- Go to settings section SSL Certificate Specific.
- 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.
Nov, 2016 - Permalink
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?
May, 2017 - Permalink
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]
May, 2017 - Permalink
Is there already an ETA when this issue will be fixed ?
Best Regards, Marc Meul
Jul, 2017 - Permalink
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]
Jul, 2017 - Permalink
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
Oct, 2022 - Permalink
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
Oct, 2022 - Permalink
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,
May, 2016 - Permalink