Univention Bugzilla – Bug 35836
SSL certificates: drop sha1 as default hashfunction
Last modified: 2014-10-30 14:11:36 CET
The default hash function for SSL certificates in UCS is still SHA-1. SHA-1 is considered less secure since researchers proved it's not collision-free in 2005 (https://www.schneier.com/blog/archives/2005/02/sha1_broken.html). Microsoft will stop accepting SHA-1-based SSL certificates that are valid beyond 2017: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx Mozilla plans to stop accepting SHA-1-based SSL certificates that are valid beyond 2017: https://bugzilla.mozilla.org/show_bug.cgi?id=942515 Google announced that they start sunsetting SHA-1 with the upcoming Chrome releases (starting with Chrome 39): http://googleonlinesecurity.blogspot.de/2014/09/gradually-sunsetting-sha-1.html Therefore we should drop SHA-1 as default hash function and choose something stronger. Additionally, it would be nice if this could be configurable through UCR.
(In reply to Michael Grandjean from comment #0) > Additionally, it would be nice if this could be configurable > through UCR. In fact there is already a UCR variable: > ssl/default/hashfunction: sha1 Nevertheless we should change the default to e.g. sha384.
ssl/default/hashfunction default is now sha384 YAML: 2014-10-15-univention-ssl.yaml
OK: r54453 RFC: openssl.cnf [CA_default] default_md=sha1 [req] default_bits=1024 This file is unused, as a file with the same name is generated by make-certificates.sh each time. IMHO it should be removed from the source code to reduce further confusion. OK: 2014-10-15-univention-ssl.yaml (configurable via [+UCR variable+] ssl/default/hashfunction) OK: annouce_errata -V 2014-10-15-univention-ssl.yaml OK: Update: ucr get ssl/default/hashfunction # sha1 FAIL: ucr set ssl/default/hashfunction=sha384 # <http://sdb.univention.de/content/15/50/en/renewing-the-complete-ssl-certificate-chain.html> rm -rf /etc/univention/ssl# apt-get {--re,}install univention-ssl openssl x509 -noout -text -in ucsCA/certs/00.pem | grep "Signature Algorithm" # Signature Algorithm: sha1WithRSAEncryption # Signature Algorithm: sha1WithRSAEncryption find -type f -exec grep -r sha {} + # ./ucsCA/CAreq.pem: Signature Algorithm: sha1WithRSAEncryption In the [req] section "default_md=..." is missing, as [CA_default] only applies to the CA and not the requester; see "man req" diff --git a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh index b7d6ba8..6b5c6b9 100755 --- a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh +++ b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh @@ -134,6 +134,7 @@ emailAddress = optional default_bits = $DEFAULT_BITS default_keyfile = privkey.pem +default_md = ${DEFAULT_MD} distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca
(In reply to Felix Botner from comment #2) > ssl/default/hashfunction default is now sha384 It seems to break the libvirt TLS connection in UCS 4.0: Bug #36324 2014-10-28 03:01:07,817 - uvmmd.node - WARNING - 'qemu://xen4.deadlock0.intranet/system' broken? next check in 0:02:00.000. authentication failed: TLS handshake failed A TLS packet with unexpected length was received. I've set the hash function again to sha1 in UCS 4.0. If this bug is fixed, please adjust the UCS 4 settings: r55055
*** Bug 36324 has been marked as a duplicate of this bug. ***
> > diff --git > a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh > b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh > index b7d6ba8..6b5c6b9 100755 > --- a/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh > +++ b/branches/ucs-3.2/ucs-3.2-3/base/univention-ssl/make-certificates.sh > @@ -134,6 +134,7 @@ emailAddress = optional > > default_bits = $DEFAULT_BITS > default_keyfile = privkey.pem > +default_md = ${DEFAULT_MD} > distinguished_name = req_distinguished_name > attributes = req_attributes > x509_extensions = v3_ca fixed (In reply to Stefan Gohmann from comment #4) > (In reply to Felix Botner from comment #2) > > ssl/default/hashfunction default is now sha384 > > It seems to break the libvirt TLS connection in UCS 4.0: Bug #36324 > > 2014-10-28 03:01:07,817 - uvmmd.node - WARNING - > 'qemu://xen4.deadlock0.intranet/system' broken? next check in 0:02:00.000. > authentication failed: TLS handshake failed A TLS packet with unexpected > length was received. > > I've set the hash function again to sha1 in UCS 4.0. If this bug is fixed, > please adjust the UCS 4 settings: r55055 sha256 seems to work, new default is sha256 Updated YAML, see 2014-10-15-univention-ssl.yaml Merged to 4.0
OK: UCS-3.2-3: r55085,r55095,r55098 OK: UCS-4.0-0: r55055,r55086,r55096,r55099 OK: openssl.cnf removed OK: [req] OK: ucr info ssl/default/hashfunction OK: annouce_errata -V 2014-10-15-univention-ssl.yaml OK: piuparts-test 2014-10-15-univention-ssl.yaml OK: Signature Algorithm: sha256WithRSAEncryption OK: virsh -c qemu://xen2/system FYI: openssl x509 -x509toreq -in ucsCA/CAcert.pem -signkey ucsCA/private/CAkey.pem -passin file:password still ope sha1WithRSAEncryption, as this doesn't use the openssl.cnf file: init() does the creation in reverse, that is it first generates a certificate and only then generates the request afterwards. Naturally one would first create the request and use that to create the certificate. Specifying an explicit "-sha256" on the command-line fixes that. As the file ucsCA/CAreq.pem is used never again in UCS (AFAIK it's only used to get the root-UCS-CA signed by some external CA), this is currently of minor importance. There is a historical report regarding the wrong algorithm in the Univention forum: <http://forum.univention.de/viewtopic.php?f=11&t=802>
http://errata.univention.de/ucs/3.2/227.html