Univention Bugzilla – Bug 40498
univention-certificate uses wrong configuration during signature
Last modified: 2018-02-05 17:53:26 CET
The univention-certificate script uses the wrong configuration during the CA signature process. This results in the wrong message digest being used. The script /usr/share/univention-ssl/make-certificates.sh's "gencert" function changes its working directory to $SSLBASE = /etc/univention/ssl. Afterwards it calls "_common_gen_cert" which in turn executes the following: openssl ca -batch -config openssl.cnf -days $days -in "$name/req.pem" \ -out "$name/cert.pem" -passin pass:"$PASSWD" -extfile "$extFile" This causes openssl to use /etc/univention/ssl/openssl.cnf instead of /etc/univention/ssl/$name/openssl.cnf. The result is that message digest set in /etc/univention/ssl/openssl.cnf is used. This is mostly an issue for systems where the admin wants to change the UCR variable "ssl/default/hashfunction" without re-generating the whole PKI. What happens when the admin sets this variable is: - /etc/univention/ssl/openssl.cnf contains the original default_md, e.g. sha1 - Newly created configuration files, e.g. /etc/univention/ssl/test-host/openssl.cnf, contain the new default_md, e.g. sha256 - However, the newly created certificate (e.g. /etc/univention/ssl/test-host/cert.pem) still uses prior message digest: sha1
In effect this means that the SDB article http://sdb.univention.de/content/15/235/en/how-can-the-hash-function-for-ssl-certificates-be-upgraded-from-md5-to-sha.html is wrong or misleading. Changing the UCR variable won't let new certificates use sha256 on upgraded systems; only doing a full re-issueance according to SDB http://sdb.univention.de/content/15/268/en/erneuern-der-ssl_zertifikate.html afterwards will ensure that.
Reported again at Ticket#2016050921000361
Well, I think the basic problem is that the base OpenSSL config file (/etc/univention/ssl/openssl.cnf) isn't touched by changing the UCR variable "ssl/default/hashfunction" but that was our assumption since the setting of an UCR variable should end in a change of a config file. @Univention staff: at the Ticket#2016050921000361 there are two small patches. Maybe you can get the fix earlier then 4.1-2-errata
(In reply to Moritz Bunkus from comment #0) > The univention-certificate script uses the wrong configuration during the CA > signature process. This results in the wrong message digest being used. Actually that is correct, as the steps to create a certificate are as followed: 1. Create public and private key at client 2. Create signing-request on client - includes public key 3. Send signing-request to CA 4. Create certificate from signing-request at CA 5. Send back certificate to client 6. Use private key and received certificate (FYI: UCS does 1. wrong(=not best-practice) and creates the private key on the DC Master (or the system used to join the computer) and copies it to the client - this helps restoring the client but increases the threat to the DC Master (and DC Backups) as all private keys are stored there and an attacker would get all them) > The script /usr/share/univention-ssl/make-certificates.sh's "gencert" > function changes its working directory to $SSLBASE = /etc/univention/ssl. > Afterwards it calls "_common_gen_cert" which in turn executes the following: > > openssl ca -batch -config openssl.cnf -days $days -in "$name/req.pem" \ > -out "$name/cert.pem" -passin pass:"$PASSWD" -extfile "$extFile" This is step 5 from above, so using the openssl.cnf from the CA is correct. > This is mostly an issue for systems where the admin wants to change the UCR > variable "ssl/default/hashfunction" without re-generating the whole PKI. > What happens when the admin sets this variable is: The problem is that the openssl.cnf file is created *once* when the initial CA is set up, that is at the time the DC Master is provisioned - the template for that file is in "make-certificates.sh". So changing the UCR variables won't change the file afterwards. r70557 | Bug #40498 ssl: Copyright 2016 r70556 | Bug #40498 ssl: cleanup r70555 | Bug #40498 ssl: Extract shared code to generate crl r70554 | Bug #40498 ssl: validate SSL setting r70553 | Bug #40498 ssl: Make hash-function and bit-count mode configurable r70575 | Bug #40498 ssl: Fix path prefix and permissions r70573 | Bug #40498 ssl: Fix ucslint r70572 | Bug #40498 ssl: Convert openssl.conf on upgrade r70571 | Bug #40498 ssl: Add unit test to check default values Package: univention-ssl Version: 10.0.0-11.168.201606230839 Version: 10.0.0-12.169.201606231402 Branch: ucs_4.1-0 Scope: errata4.1-2 r70577 | Bug #31369,Bug #39257,Bug #24094,Bug #40498,Bug #25285,Bug #35748: ssl YAML univention-ssl.yaml
Code review: OK Advisory: OK Tests: OK
<http://errata.software-univention.de/ucs/4.1/213.html>
(In reply to Philipp Hahn from comment #4) > r70553 | Bug #40498 ssl: Make hash-function and bit-count mode configurable This breaks <http://wiki.univention.de/index.php?title=Cool_Solution_-_Creation_and_management_of_user_and_Windows_certificates>, as "DEFAULT_MD DEFAULT_BITS" are not passed through the environment variables. git@univention.plan.io:univention-00000-intern.cool-solution.git[ucs-4.0/master] Package: univention-usercert Version: 4.0.6-2.41.201607261628 Branch: ucs_4.1-0 Scope: cool-solutions