ONTAP Discussions

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 ?



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


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.