Webmin/Virtualmin encryption with SHA1

Hi,

As SHA1 is now obsolete, I wondered if there is any way to update the encryption Webmin and Virtualmin uses to SHA256. Is it possible to generate your own key and certificate with SSH and just replace the file in /etc/webmin/miniserv.pem?

Thanks for any help.

Philip

Howdy,

When generating a key, it actually defaults to SHA2 now. However, that’s configurable.

In Server Configuration -> Manage SSL Certificates -> Create Signing Request, there is an option named “Certificate hash type”.

It defaults to SHA2 – you’d just need to make sure that’s what any new keys are set to.

Regarding existing SSL certificates – you would need to generate a new CSR and private key, and then have your SSL certificates re-issued. Once you do that, they should be using the updated hash algorithm.

-Eric

Thanks for the advice Eric

I am having problems where Chrome is repeatedly closing down my webmin/virtualmin sessions (Webmin version 1.760, Virtualmin version 4.18.gpl, CentOS 6.6). In addition to not liking the server certificate, Chrome initially complained that “Your connection to …is encrypted using an obsolete cipher suite.” The certificate details showed Signature algorith=sha1RSA, Signature has algorithm=sha1

I tried to follow the instructions above but the only place I could find was Webmin -> Webmin configuration -> SSL Encryption / Self-Signed Certificate. I created a new certificate (I could find no option to set SHA2) but Chrome still claims the certificate is using SHA1. Chrome says the connection method is TLS 1.2 (which I think is OK) but that the encryption is AES_256_CBC with HMAC-SHA1 message authentication and RSA as the key exchange.

Is there somewhere else that I should be looking to create the self-signed certificate?

Thanks, Norbert

It would appear the webmin and openssl do not automatically create SHA2 certificates. I followed the instructions at http://blog.rimuhosting.com/2014/11/18/webmin-sec-err-invalid-key/ but added the ‘-sha256’ option. Running ‘openssl x509 -in miniserv.pem -text’ verified that the certificate is now signed with sha256WinRSAEncryption.

I also changed the ‘SSL protocol version’ to ‘10’ in Webmin Configuration -> SSL Encryption / SSL Settings’. Chrome still complaining but I am not losing the Webmin session. Usermin also needs to be updated - it has less strict settings that the default for Webmin.

Hi nh905,

Thanks for the update. I think Eric misread my question and I have been ill for 4 weeks so have not replied.

Where you typed in “10” that is not a protocol. The next field down shows the available protocols. You should be using TLSv1.1 or TLSv1.2. If you use Apache they are only available in Apache 2.4 (not 2.2).

I tried the following to generate an elliptical curve algorithm but Webmin would not restart.

openssl ecparam -list_curves
To establish curves available .

openssl ecparam -name secp521r1 -genkey -out private-key.pem
To generate the key

openssl req -new -x509 -key private-key.pem -out server.pem -days 730
To generate the self-signed certificate

cat private-key.pem server.pem > /etc/webmin/miniserv.pem
To place the key and certificate in the pem file.

service webmin restart to restart webmin

The message I received was-
Failed to open SSL key /etc/webmin/miniserv.pem at /usr/libexec/webmin/miniserv.pl line 4312.

This line reads -
$ssl_ctx, $keyfile,

I also noticed another minerv.pem in this directory.

Completely lost now lol

I generated an RSA SHA512 certificate and Chrome told me the cipher was obsolete (AES_256_CBC for encryption, HMAC_SHA1 for message authentication and RSA as the key exchange mechanism). I am using field ciphers for perfect forwarding secrecy.

After some reading I changed “Force use of server-defined cipher order?” to yes and in cipher list I typed

ALL:!ADH:!RC4:!LOW:!MEDIUM:!SSLv2:!SSLv3:!TLSv1:!EXP:+HIGH
(TLSv1.1 does not have a specific cipher list)

I am now getting AES_128_GCM for encryption and message authentication and RSA as the key exchange mechanism.

After reading some articles from2014 I learned that both AES_128_GCM and AES_256_GCM are unbreakable and preferred over AES_128_GCM. Interestingly Chrome is still saying the ciphers are obsolete.

I am using CentOS 7.1.1503 and my rkhunter scans are telling me apache and openssl versions are out of date. I don’t know if this part of the problem. CentOS are more interested in security and reliability over “cutting edge” from what I have read. From my experience it does seem that certain updates have long delays.

Philip

Hi Philip, after too many hours of testing last night, it turns out that my problem may have had nothing to do with the SHA1 miniserv.pem SSL certificate, although I still need to do more testing to confirm. To recap, until recently I have been able to access virtualmin using Chrome so long as I accepted the warning. In the last week or so, I can connect but the connection fails after a few minutes. I could not find a good match - various people have reported problems with Chrome and SHA1 SSL certificates which is how I ended up here. Other posts on virtualmin forums referenced SSL connection issues and recommended ssl_version=10.

It turns out that setting ssl_version=10 reverted my connection from TLS 1.2 to TLS 1.0, even through I had checked that TLS 1.0 and TLS 1.1 were not to be used. What fixed my Chrome connection problems was adding the webmin self-signed certificate to the Chrome Trusted Root Certificates list, a relatively easy procedure once you know the magic incantation.

At first glance, it appears Chrome is clamping down on self-signed certificates. I still need to roll back my changes to verify and also ensure that the way I access virtualmin is not causing problems.

repeat please delete

I think all browsers give a warning page for self-signed certificates. Not sure why this would cause a connection to drop after a few minutes.

I never thought of adding the certificate to Chrome’s certificate store. Think i will read up on this.

I could not reproduce the connection drops when I was accessing virtualmin using the stock method. It appears that the connection drops related to the way I was accessing virtualmin. Rather than opening more ports on my server, I tunnel port 10000 and 20000 through an SSH connection. Not sure how that is related but the problem is resolved by getting Chrome to recognize the self-signed certificate.

From Webmin Configuration -> SSL Encryption / Current Certificate, I exported it in PKCS12 format. In Chrome Settings click on the Advanced settings link and then click on ‘Manage certificates’ under HTTPS/SSL. Import the webmin certificate into the Trusted Root Certification Authorities and restart Chrome.

I added the miniserv.pem file originally created during the webmin install without any problems but Google would not trust the certificate. I suspect that the problem is the server name ‘*’ in the certificate. I created a new certificate using the server ‘localhost’ (I access vritualmin through localhost since I am tunneling) and repeated the procedure above. Still no joy - this time Chrome complained about a certificate in the chain being signed using SHA1.

I created an SHA2-compliant certificate using the code below, once again imported it (after removing the old certificate from Chrome), restarted Chrome and voila, I now have a green lock symbol without any disconnects. Replace with text in <> with your specific information

file=/etc/webmin/miniserv.pem
openssl req -x509 -newkey rsa:2048 -keyout $file -out $file
-days 3650 -sha256 -nodeON/L=/O=webmin/CN="
openssl x509 -x509toreq -in $file -signkey $file >> $file

Thanks for this. I will give it a try.

I noticed that the script to generate the new sha2 certificate is not displaying correctly. There are three lines:

 file=/etc/webmin/miniserv.pem

sets a variable used in:

 openssl req -x509 -newkey rsa:2048 -keyout $file -out $file \ -days 3650 -sha256 -nodeON/L=/O=webmin/CN="

and:

 openssl x509 -x509toreq -in $file -signkey $file >> $file