This article applies as of PRTG 22
Monitoring web pages that use SNI for SSL handling
With PRTG 15.4.21, we introduced an automatic Server Name Indication (SNI) support for the HTTP and HTTP Advanced sensors. 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 web page, this change can result in malfunctioning sensors that had previously been working correctly.
SNI detection
A web server that enforces the use of SNI, a TLS extension, must 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 device settings. If it is not a 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 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 must throw an error because of an unknown SNI host or which type of error it must 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 the sensor settings, check the Server Name Indication 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 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 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 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.
Add comment