New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


SSL Sensors & Subject Alernative Name(SAN) Certificates

Votes:

0

Your Vote:

Up

Down

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 by  amikolajczyk (110) 1

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



Best Answer

Accepted Answer

Votes:

1

Your Vote:

Up

Down

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]



7 Replies

Votes:

1

Your Vote:

Up

Down

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 Support]



Votes:

0

Your Vote:

Up

Down

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 by  amikolajczyk (110) 1



Accepted Answer

Votes:

1

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  almazov (0)



Votes:

0

Your Vote:

Up

Down

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 Support]



Votes:

0

Your Vote:

Up

Down

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

Best Regards, Marc Meul

Created on Jul 20, 2017 8:44:19 AM by  PerplexMM (0)



Votes:

0

Your Vote:

Up

Down

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 Support]



Please log in or register to enter your reply.


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.