Hello and thank you for your post.
Please note that the HTTP SSL Certificate Expiry was recently deprecated. You should now use the new "SSL Certificate Sensor", which has the same/more capabilities and supersedes the old sensor. The new sensor is also more performant and less error-prone.
Please be aware that this sensor works a bit differently from the old one. As were the old 'HTTP SSL Certificate Expiry' could be placed on any device and monitor any URL, the new sensor will always query it's parent device, which 'fits nicely' with PRTG's concept of sensors x devices. This also increases the sensor's compatibility with the Auto-Discovery.
For instance, to monitor the certificate for https://www.zenito.be the device's address must be the FQDN www.zenito.be for best results. (It could also be the IP, but to cope with changing IP's the FQDN is the best option).
While deploying the sensor on the newly created device you will only need to enter a port (For HTTS, usually 443, default).
Should this FQDN/Server be able to provide multiple SSL Certificates (trough Server Name Indication) this can also be configured within the sensor's settings. In this case use multiple sensors with different SNI's to query multiple certificates from the same device.
I've tested the mentioned URL/FQDN with PRTG 184.108.40.20624 and I'm able to confirm that the sensor is working. Please let me know if the new sensor works for you.
Conceptually using URL's for this sensor didn't make much sense, since the SSL Configuration is always defined for the whole webserver/ip/socket, and all sub-pages of the website will be provided by the same webserver/ip/socket. The new sensor doesn't use HTTP Requests but does a low-level SOCKET connection, making this sensor compatible not only websites that use SSL but with any socket that implements SSL, example: SMTPS, POP3S, 3rd-party protocols with SSL.
Here's a second example of the SSL Certificate Sensor's usage:
Luciano Lingnau [Paessler Support]