I’m currently on the edge track and upgraded a number of modules over the last couple of days including Certman that have improved HTTPS/TLS support. I’ve found two bugs/issues:
-
I was using a third party issued Certificate for HTTPS access to the GUI prior to this upgrade without issues. I successfully imported that certificate from the System Admin module into Certman and then went back to SysAdmin and reselected it to make sure it was set as the certificate for Apache. Everything was working fine. This was two days ago. Each morning since, I have attempted to log into the GUI and been greeted with a warning on my browser saying that my certificate isn’t trusted. I’ve ignored that, gone to Sysadmin and found that my Apache Certificate has changed back to the Default one Certman sets up when it installs. I change it back to the third party one and everything is OK again until the next morning. I’ve even selected the third party cert as the default and its still happening. Something seems to be resetting this overnight. I can’t see anything in the logs though. Any assistance in figuring out why this gets reset everynight would be appreciated.
-
Yesterday I noticed that I can’t connect to the gui using Safari on either OS/X or iOS (multiple devices) via HTTPS with the default Cipher Suite settings in ssl.conf. I can connect without issues using Chrome (OS/X, Windows) and IE and Edge without any issues. The error I get is that Safari “can’t establish a secure connection to the server”. I enabled the debug setting and have captured logs (can send them to the devs but not posting them here):
Safari connections fail with:
SSL Library Error: 336109761 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher Too restrictive SSLCipherSuite or using DSA server certificate?
If I change the default SSLCipherSuite from
AES128+EECDH:AES128+EDH
to something less restrictive (compatibility settings from https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html accessed via https://cipherli.st)
EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
then Safari negotiates a connection using
Protocol: TLSv1.2, Cipher: AES256-GCM-SHA384 (256/256 bits)
It seems like Safari would really prefer to use a different cipher than the ones setup as defaults and throws its toys out of the cot when it can’t find the ones it wants.
Hope this helps track down the issues. I’ll post a bug report once its agreed that they are definite issues.