Subscribe
Accepted Solution

Autosupport over HTTPS breaks when disabling SSL2+SSL3

Hello communitie,

 

To enforce security I recently disabled SSLv2 and SSLv3 on our filers running Data OnTap 8.2.3 7-Mode, using the command options ssl.v3.enable off

 

But I noticed that MyAutosupport was no more updated since then, and retrieved these error messages in the /etc/log/mlog/notifyd.log file

 

00000024.0009a665 005c5350 Fri Jan 29 2016 10:28:21 +01:00 [kern_notifyd:info:854] 0x8096babc0: ERR: AutoSupport::OnDemand: SSL certificate problem, verify that the CA cert is OK. Details:

00000024.00099832 005bc6b1 Fri Jan 29 2016 09:28:21 +01:00 [kern_notifyd:info:854] error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

00000024.00099833 005bc6b1 Fri Jan 29 2016 09:28:21 +01:00 [kern_notifyd:info:854] 0x8096babc0: ERR: AutoSupport::OnDemand: Unable to send polling query to ASUP OnDemand Server

00000024.0009a664 005c5350 Fri Jan 29 2016 10:28:21 +01:00 [kern_notifyd:info:854] 0x8096babc0: ERR: AutoSupport::OnDemand: Unable to send AOD request to OnDemand Server: Peer certificate cannot be authenticated with known CA certificates

 

I solved the problem by configuring autosupport to use HTTP instead of HTTPS, but this is not satisfying - thus my question :

 

Does Autosupport On Demand supports HTTPS over TLS ?

 

Since the error mentions SSL3_GET_SERVER_CERTIFICATE, I have some doubts...

 

Of course I doubled-check that the root certificate is valid and copied in /etc/keymgr/root/cacert.pem - when I contact the filer using https://filer I can see that the certificate is valid.

 

Could someone shed the light on this problem ?

Re: Autosupport over HTTPS breaks when disabling SSL2+SSL3

Re: Autosupport over HTTPS breaks when disabling SSL2+SSL3

Can you check if the environment is using a HTTP proxy?  This might be a certificate issue with the proxy - not NetApp AOD server. 

Re: Autosupport over HTTPS breaks when disabling SSL2+SSL3

This problem is solved - thanks for your useful hints, hariprak and andris.

 

In fact the problem was that I installed a C.A.-signed certificate instead of the default self-signed one, and that I installed the certificate of our Certificate Authory in /etc/keymgr/root/cacert.pem

 

I took some time to realize that the original cacert.prm file was a collection of Root C.A. certificates, not only one certificate for one C.A. !

 

Setting back the original cacert.pem file solved the problem.

 

Maybe this documentation should be more clear about the content of this file ?

 

Thanks again anyway.