català | [[Roots/Class3ResignProcedure/CZ|česky]] | dansk | deutsch | '''english''' | español | français | lingála | magyar | nederlands | norsk | polski | português | svenska

 . '''To [[Roots|New Roots & Escrow Project]]''' - '''To [[Roots/Class3ResignProcedure|Class3 Re-sign Procedure]]''' - '''To [[Roots/Class3ResignProcedure/Migration|Class3 Re-sign Project Overview]]'''
 . '''To [[Roots/Class3ResignProcedure/FingerprintSources|Class3 Subroot Fingerprint - Sources]]''' - '''To [[Roots/Class3ResignProcedure/PR-DistributionList|PR Distribution list for Class3 Re-sign Project rollout]]'''

----

= Class 3 Certificate Re-sign Procedure =

here is the proposed procedure to generate a new Class 3 cert with a
non-MD5 hash-algorithm. This is because in June Mozilla will refuse to
accept any non-self-signed certs that are signed using MD5. This
procedure is essentially a renewal of the Class 3 cert and has been
tested on the test server of the Software Assessment Team
https://cacert1.it-sls.de

The procedure has to be executed on the signer. I will first give a
step-by-step guide without explanations, the explanations for each step
then follow below:

 1. In the file "/etc/ssl/openssl-ca.cnf" change the value of "{{{my_policy_oid}}}" to "{{{1.3.6.1.4.1.18506}}}" (on line 7). See the attached patch.

 2. Backup the old Class 3 certificate (e.g. by copying it "{{{cp /etc/ssl/class3/cacert.crt /etc/ssl/class3/cacert_md5.crt}}}")

 3. Generate a Signing Request for the Class 3 (if there is one present already skip to the next step). To do this change into the "/etc/ssl/" directory and then execute "{{{openssl req -config openssl-ca2.cnf -out class3/cacert.req -new -key class3/cacert.pem}}}". It will prompt for the password to the private key of the Class 3 cert. All questions about Organisation etc. should be just confirmed by hitting the return key.

 4. Generate a signed certificate from the request: "{{{openssl ca -config openssl-ca.cnf -in class3/cacert.req -out class3/cacert.crt -notext -days 3650 -md sha256 -extensions v3_ca}}}". It will prompt for the password to the private key of the Root cert. The question whether the operation should be committed should be confirmed after verifying that the information that is printed is correct.

 5. Verify that the certificate generated is similar to the old one (e.g. by comparing the outputs of "{{{openssl x509 -text -noout}}}"). It is '''very important''' that the "Subject" lines and the RSA public key match exactly. Things that should have changed:
  * Serial Number
  * Signature Algorithm (should now be "sha256WithRSAEncryption")
  * Validity
  * X509v3 Subject Key Identifier
  * X509v3 Authority Key Identifier
  * Netscape CA Policy Url
  * Netscape Comment
  * Signature

 6. Copy the new cert onto some medium so we can deploy it later

 7. At this point the signer could be stuck for some reason (have a look at the logfiles and nohup.out for errors). At least it was on the test server. I don't know what did the trick but I stopped the signer and the CommModule of the webdb ("{{{/etc/init.d/commmodule stop}}}"), removed its work directory ("{{{rm -r <path_to_signer>/CommModule/work/}}}"), removed the *.crl.patch files in the webdb ("{{{rm /home/cacert/www/www/class3-revoke.crl.patch /home/cacert/www/www/revoke.crl.patch}}}") and restarted both ends again.

 8. Deployment. There are quite some bunch of places where the new fingerprints have to be stored (cap forms, root page, marketing material, etc.) so we better wait with the deployment for a few days, prepare the patches for all relevant places (can't do that without knowing the new fingerprint, which is kind of hard to do in advance) and then deploy them in one go. The deployment would be: store it as is in /home/cacert/www/www/certs/class3.crt then "{{{openssl x509 -in /home/cacert/www/www/certs/class3.crt -outform DER -out /home/cacert/www/www/certs/class3.der}}}" and "{{{openssl x509 -in /home/cacert/www/www/certs/class3.crt -text -out /home/cacert/www/www/certs/class3.txt}}}"


So here's the explanation for each step:

 1. The currently present OID is bogus (unless we have anything to do with Kerberos). The value 1.3.6.1.4.1.18506 is our own OID base (see [[OidAllocation]]) which is not optimal, probably the value 1.3.6.1.4.1.18506.2.3.1 would be better but then again the old cert also had the former value and I guess no client implements this policy stuff anyway (because it's damn complicated) so let's just use the old value.

 2. <void>

 3. The right values for Organisation & Co. should already be predefined in the config file

 4. I've assumed that 10 years life time is OK here. The old cert had a longer life time but we want to switch to other roots anyway so let's set a deadline. I've opted for SHA-256 instead of SHA-1 because there are known flaws in SHA-1 which are not critical yet but we don't want to have to do this whole thing again if it hits in a few years. We could also use SHA-512.

 5. The subject and public key has to stay the same because otherwise we can't just continue signing CRLs for old certs and also those old certs might no longer validate. The serial number changes because serial numbers have to be unique for a CA. Changing the Signature Algorithm was the whole point. Validity changes because the cert is valid from the current date. X509v3 Subject Key Identifier, X509v3 Authority Key Identifier, Netscape CA Policy Url, Netscape Comment are not present in the old cert but I chose to include them in the new one because otherwise more of the openssl-ca.cnf must have been changed, they can't harm (they're also present in the root), and having the Identifiers is actually a feature (if we ever want to do a key rollover, they help clients to distinguish what cert to use, the old or the new one, in order to verify an end user cert).

 6. <void>

 7. I have really no idea what made the signed throw up, maybe it was a side effect from some other work I did simultaneously

 8. The most important place is the root cert page, email footers, and the CAP forms. Fortunately most CAP forms and email footers contain only the finger print of the Class 1 root as far as I can tell but there are probably also some places where I haven't looked. We should also do a blog post, a mailing list announcement and what other channels we can think of. Also we have to tell all owners of a server cert that they should replace their chain files (I don't know if there's any action required for email certs) and generally all users who have imported the Class 3 should update it. Otherwise they might see some strange error messages in June.

----
 . CategoryAudit
 . CategoryNewRootsTaskForce
 . [[Roots/StateOverview|Root States Overview]]