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


My HTTP sensors fail to monitor websites which use SNI. What can I do?

Votes:

0

Your Vote:

Up

Down

I use HTTP sensors to monitor various external webpages. Some of these sensors fail to successfully check their target websites. For example, I get the following HTTP sensor errors depending on the monitored webpage and when SNI is used for SSL handling:

  • Application protocol errors: 403 Forbidden, 400 Bad Request
  • SSL/TLS protocol errors: Failed to establish secure connection, Error connecting with SSL, SSL handshake failure

What can be the reason for these protocol errors? Why do I get SSL handshake failures?

error error-messages http http-sensor https protocol prtg sni ssl tls

Created on Dec 9, 2015 2:47:51 PM by  Gerald Schoch [Paessler Support]

Last change on Jul 18, 2019 11:40:44 AM by  Maike Behnsen [Paessler Support]



16 Replies

Accepted Answer

Votes:

1

Your Vote:

Up

Down

This article applies to PRTG Network Monitor 19 or later

Monitoring Webpages that Use SNI for SSL Handling

With PRTG version 15.4.21, we introduced an automatic Server Name Indication (SNI) support for the sensor types HTTP and HTTP Advanced. As of this version, you can monitor, for example, external websites behind a reverse proxy that uses SNI for its SSL handling.

Note: Depending on the current endpoint configuration of the target webpage, this change can result in malfunctioning sensors that have been working correctly so far.

SNI Detection

A web server that enforces the use of SNI, a TLS extension, has to be queried with a mapping string, usually the Fully Qualified Domain Name (FQDN) of the host, to monitor according websites with HTTP sensors. The sensor first tries to set SNI to the host address of the parent device of the HTTP sensor, as specified in the Basic Device Settings. If it is no valid FQDN, the sensor tries the host part determined from the target URL of the sensor.

If this results in a valid SNI, the sensor shows this SNI in the sensor settings under Server Name Indication in section HTTP Specific.

As of PRTG version 16.1.23, you can disable SNI inheritance from the parent device in the settings of an HTTP sensor. In the settings section SNI Inheritance, select the option Do not inherit SNI from parent device to determine the SNI only from the target URL of the sensor.

HTTP Error Handling

The used RFC (Request for Comments) does not specify if the server has to throw an error because of an unknown SNI host or which type of error it has to throw at all, so you can encounter the following situations with HTTP sensors, based on our experience:

1. Your HTTP sensors work fine after this PRTG update.

Perfect, enjoy monitoring your websites. You do not have to take care of the SNI configuration.

2. You get an SSL/TLS protocol error.

This error can be, for example: Failed to establish secure connection [Step 0] Error connecting with SSL. Error connecting with SSL. error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure [Step 1] Error connecting with SSL. Error connecting with SSL. error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure [Step 2] Error connecting with SSL. Error connecting with SSL. error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure [Step 3] Error connecting with SSL. Error connecting with SSL. error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure [Step 4] Socket Error # 10054 Connection reset by peer. [Unsecure] IOHandler value is not valid

Solution: In your sensor's settings, check the Server Name Indication (SNI) field in section HTTP Specific. This field displays the SNI that the sensor uses when it connects to the target server (see section SNI Detection above). To get a working connection to the target server, either change the host address of the sensor’s parent device or change the target URL of the sensor according to the configuration of the target server.

3. You get an application protocol error.

This error can be, for example: 403 Forbidden or 400 Bad Request

Solution: In your sensor's settings, check the Server Name Indication (SNI) field in section HTTP Specific. This field displays the SNI that the sensor uses when it connects to the target server (see section SNI Detection above). To get a working connection to the target server, either change the host address of the sensor’s parent device or change the target URL of the sensor according to the configuration of the target server.

4. The error persists even after you checked (2) and (3)

Solution: Check the target server's virtual host configuration.

For example, https://www.example.com and https://example.com are two different vhost configurations and can use different SNI settings. Also check if your endpoint uses a redirect to a different host address.

Created on Dec 9, 2015 2:53:04 PM by  Gerald Schoch [Paessler Support]

Last change on Jul 25, 2019 9:43:45 AM by  Maike Behnsen [Paessler Support]



Votes:

1

Your Vote:

Up

Down

There is a very thoughtless assumption built in to how SNI is implemented for these HTTP sensors.

We have several devices which have a dedicated host name that has no relation whatsoever to the hostnames of sites being served on the device. The first FQDN tried should be that of the sensor it self, not the parent device. If the order of data points to check must remain the same, at least make the new SNI attribute editable!

At this point, I see no other way to fix this than to create new dummy devices specifically for each website just for the sake of the device hostname matching the FQDN of the HTTP sensor - absurd!

  • edit Jan 25, 2016 - Based on the replies below from the PRTG support/dev team, it sounds like this won't be changing. As a workaround, I have created a group in place of the original device, moved the device into that group and then created website devices in the group with hostnames that match the sensor. Not ideal, but it will do. @PRTG support - Thank you for following up so we at least know this won't be changing.

Created on Jan 21, 2016 2:44:51 AM by  ym-admin (10) 1

Last change on Jan 26, 2016 8:19:08 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thank you very much for your response. We talked about the issue with the SNI name field and HTTP Sensors with our development team, and the current workflow will not be changed. We understand that this is not straight forward and the same for all sensors, which is something we are not really happy ourselves. We do have a strict inheritance in mind here, and right now the HTTP Sensors are the once behaving "correctly", because they stick to the conventions we set in the object hierarchy. So this means that it will be necessary to split the HTTP Sensors onto separate unique devices, which have proper entries in the DNS-name field. Sorry.

Created on Jan 22, 2016 1:31:19 PM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I would have to 100% agree with ym-admin. We monitor all our external sites under one device. A deny inheritance on the one setting for http sensors at least would be nice...

Created on Jan 22, 2016 4:14:27 PM by  tom234679 (252) 1



Votes:

0

Your Vote:

Up

Down

I totally agree with vm-admin, this is absurd. I suggest that you provide this new http sensor along with the old one to maintain already established monitoring setups. I m not very happy with a change like this. Another option might be to have a sensor that monitors name based virtual hosts even if ssl is used...eitherway, the result is the same...it is : providing a sensor with the old functionality. And IMHO your arguments dont count very much, as vm-admin states, a servicename is a propperty of a physical host and there can be many servicepoints per host. It simply makes no sense to split these servicepoints from the host and then, instead, monitor some "dummy" devices...

Created on Jan 22, 2016 5:15:22 PM by  AndreasHuemmer (300) 2 1



Votes:

0

Your Vote:

Up

Down

I understand that you would prefer a different behaviour. Please be aware though that, at the moment, there are no plans to change this from the development team. Sorry.

Created on Jan 25, 2016 8:31:45 AM by  Torsten Lindner [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I agree that this seems like a very bizarre way of designing these sensors. More specific settings (the settings on the sensor) should always override more general settings (the settings on the device). Every other setting on the sensor works this way - you can either inherit or override proxy settings, scanning interval, schedules, etc. Why not the SNI?

Since, according to the mouseover on the SNI field, the SNI can be taken either from the device or the sensor it should at the very least allow the user to decide which of these to use. This forced inheritance is not only unhelpful but counter-intuitive. Given the previous comments from other users it seems that you've made a design decision without focusing on the needs of your customer base.

Created on Jan 26, 2016 11:25:45 AM by  IanTW (1) 1



Votes:

0

Your Vote:

Up

Down

I don't understand this problem well enough to comment at this time. It's possible for original concern actually has another root cause.

Created on Feb 2, 2016 12:34:05 AM by  Curtis Kayfish (70) 2 1

Last change on Feb 4, 2016 12:19:15 PM by  Torsten Lindner [Paessler Support]



Votes:

1

Your Vote:

Up

Down

We also use a single device to monitor multiple websites which have nothing to do with each other. I initially had the object's DNS/IP address set to "none" which counted as a valid FQDN, and was therefore used in the sensor.

According to the OP (Gerald, Paessler Support):

  • The sensor first tries to set SNI to the host address of the parent device of the HTTP sensor, as specified in the Basic Device Settings. If it is not a valid FQDN, the sensor tries the host part determined from the target URL of the sensor.

I changed the parent object DNS/IP field to "none.invalid/" (yes, include the slash). That caused the sensor to use its host part from its own URL field, rather than the parent object's DNS/IP field since it is not a valid FQDN.

Hope this helps.

Created on Feb 12, 2016 3:10:33 PM by  Ben Claussen (10)



Votes:

0

Your Vote:

Up

Down

Thanks to Mr. Claussen for the fix. It worked for me as well.

Once again, I'm a bit astonished at the attitude of the development team towards their customers. This is the sort of approach that sends customer to other products.

Created on Feb 16, 2016 7:44:19 PM by  Bob D (0) 1



Votes:

0

Your Vote:

Up

Down

Thank you for the good advices, that helped me a lot for checking external Websites. But how to handle local websites without FQDNs for example the config-site of a switch which is only available over "http://12.34.56.78/" ? Either the advice to configure the main device nor the "none.invalid/" trick was useful. I get the "Bad request" answer ... Any ideas?

Created on Apr 18, 2016 8:32:20 AM by  Lanzke, Fa. Maxfeld (0)



Votes:

0

Your Vote:

Up

Down

@Lanzke, Fa. Maxfeld: does the website redirect to HTTPS? Could you possibly check the webserver logs to see what exactly goes wrong?
Best regards

Created on Apr 18, 2016 1:10:42 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

We have six web servers in our server farm and we use the same IP addresses for multiple URLs on those host. How do I set up monitoring for this?

www.test1.com
www.test2.com
www.test3.com
https://10.0.0.1/welcome.aspx
https://10.0.0.2/welcome.aspx
https://10.0.0.3/welcome.aspx
https://10.0.0.4/welcome.aspx
https://10.0.0.5/welcome.aspx
https://10.0.0.6/welcome.aspx

Created on Aug 24, 2016 7:31:59 PM by  TimWeber501 (0)

Last change on Apr 18, 2018 6:55:14 AM by  Luciano Lingnau [Paessler Support]



Votes:

0

Your Vote:

Up

Down

@TimWeber501: Here you would have each webserver as single device in PRTG. You then can set the SNI to the websites used on those servers.
E.g.:

Device: 10.0.0.1 -> HTTP Sensor -> SNI: test1.com
Device: 10.0.0.1 -> HTTP Sensor -> SNI: test2.com

Best regards

Created on Aug 26, 2016 1:31:11 PM by  Konstantin Wolff [Paessler Support]

Last change on Aug 26, 2016 1:31:19 PM by  Konstantin Wolff [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I'm still not getting it to work. Can we arrange for a phone call to resolve this?

Tim

Created on Aug 26, 2016 1:58:51 PM by  TimWeber501 (0)



Votes:

0

Your Vote:

Up

Down

@TimWeber501: Please open up ticket with [email protected]. We will handle this further via ticket then. When doing so, please refer to this thread and also submit a support bundle.

Created on Sep 1, 2016 1:15:27 PM by  Konstantin Wolff [Paessler Support]

Last change on Sep 1, 2016 1:16:17 PM by  Konstantin Wolff [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.