A couple of bugs 1.2.1

I had time to test it.

wont work.

works fine

yes,

works fine

@TheCry @Cool

Thank you both

@Nuxwin
I have a question about the 1.2.1. Did you changed something in the SSL support?
Because my monitoring checks all the SSL cert with this command

and i got the response from the panel cert.

This works all the time. But after installing 1.2.1 i need to add a parameter "--sni".
I have another server with 1.2.0 and there is no need to add this parameter.

@TheCry

Hello ;

I presumes that you're talking about customer's SSL certificates, right?

Well, the only changes I've made regarding the SSL feature is to use the PHP openssl library to validate certificates through the frontEnd instead of the phpseclib library. This has been needed to allow usage of CA certificates provided by the OS ( ca-certificates packages ) to validate the certificates, and also, to solve the recurrent problem regarding users ( noobs ) which are not able to provide the full CA chain ( eg. by including the CA root in their CA bundle ).

From now, only intermediate certificates, which are not known by the OS, are required in the CA bundle. Apart this change, I've made nothing special in the way the SSL certificates are configured in Apache vhost files.

Anyway running your check_http monitoring plugin without the --sni option was a mistake because if the SNI support is not enabled, and if many SSL certificates are available for the same IP, the server ( Apache ) always answer with the default SSL certificate ( the first found ). The --sni option only tells your check_http plugin to send the name of the domain ( host ) as part of the TLS negotiation. This allow Apache to know the target vhost to use, and thus, the SSL certificate to use.

What you mean by ----> "and i got the response from the panel cert."? if you want say that without the --sni option, the server is answering with the panel certificate, this is not normal because the panel is running through an other httpd instance ( nginx ). Are you using the panel redirect plugin?

Anyway, without the --sni option, the certificate that is presented should be the first certificate available for the IP which belongs to the domain ( host ) as set by the -H option of your plugin. Then, if the server doesn't answer correctly for this SSL certificate , or if the certificate is expired ( according your other plugin parameters ---> -C ), you'll get an error.

As I understand, you want to know when a site is down but also when a certificate is on the point to expire. Well, running the plugin without the --sni option will give you inaccurate informations because those informations will always be based on the first SSL certificate found by the server...

Refs

• https://www.monitoring-plugins.org/doc/man/check_http.html

Note: Thread moved outside of our internal forum because it contain interesting information for our community.

I use the monitoring of the ssl only to get the expired informations.

Quote from Nuxwin

@TheCry
What you mean by ----> "and i got the response from the panel cert."? if you want say that without the --sni option, the server is answering with the panel certificate, this is not normal because the panel is running through an other httpd instance ( nginx ). Are you using the panel redirect plugin?

Correct.. The server answers with the panel cert. Yes the latest version of the redirect plugin is installed.

I know about the whole parameters of the check plugin, and the monitoring was running fine before upgrading the server to 1.2.1.
That is the reason why i ask you, whether there was something changed. Before upgrading on the server was 1.1.1 installed and the cert monitoring doesn't need the sni parameter.
The same on a second server. This was a fresh installation with 1.2.0. The plugin "Panel Redirect" ist installed there, too. And i don't need the sni parameter.

Maybe i can upgrade the server to 1.2.1 and i will see whether i got the same behavior.

@TheCry

If you're using the PanelRedirect plugin and run the monitoring plugin without the --sni option, it's normal that the presented certificate is the one from the panel because this is the first vhost loaded. I've already explained the reason in my previous post. If this worked before, without the --sni option ( which I doubt ), this is not normal

@Nuxwin
I'd figured it out. The problem is the plugin "ServerDefaultPage"
After deactivating this plugin the monitoring of the certs without --sni works like before.

@Ninos
I think here you need to check the plugin.

@TheCry

There is nothing to check You must activate the SNI option You should also learn a bit more about Apache (eg https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI )

In your case, the certificate set in the SSL vhost that is configured by the ServerDefaultPage, and which act as a catchall, is served because you run your monitoring plugin without the SNI feature, and thus, apache doesn't know for which hostname the SSL request is made. There is nothing complicated to understand here. It is so hard to enable the --sni option?

@Nuxwin
I don't need to learn a little more about Apache. Apache SNI support is known by me. Now i did take a look in the plugin and i see how the plugin works.
No. It's simple to implement.
Thanks for the support. You find every time the correct and professional words..