WWUCA

University of Münster Certification Authority

• Rainer Perske

• Westfälische Wilhelms-Universität
  Zentrum für Informationsverarbeitung
  Zertifizierungsstelle
  Röntgenstraße 7-13
  48149 Münster

• ca@uni-muenster.de
  +49 251 83 31590 (fon)
  +49 251 83 31555 (fax)

What is a certificate?

How do you request a certificate?

Certificate (simplified example)

• Public Key: Algorithm RSA, Exponent 65537; Modulus e3 d2 10 ... 50 4a 85

• Subject (certificate owner): CN=Rainer Perske, O=Universitaet Muenster, C=DE

• Issuer (certification authority): CN=Zertifizierungsstelle, O=Universitaet Muenster, C=DE

• Serial number: 13:95:13:C7:CD:EA:2E; version: 3 (has extensions)

• Valid from 2012-03-30 11:17:11 UTC to 2015-03-30 11:17:11 UTC

• Extension: Usage: signing, key encryption (for mail, TLS, Smartcard-Login), but not as CA

• Extension: Alternative names: E-Mail perske@uni-muenster.de, Login: perske (uni-muenster.de)

• Signature for all data above, created with the private key of the certification authority:
  Algorithm: PKCS #1 SHA-256 with RSA, value: 81 5c 3e ... a8 eb 40

• The certificate does not contain the owner's private key!

Requesting a user certificate from the WWUCA

• Generate a key pair

• Upload public key + personal data, signed with the private key, to the WWUCA

• Print the application form containing the fingerprint of the public key and further data

• All above in one step: http://ca.wwu.de ⇒ Nutzerzertifikat

• Sign the form and thus declare that the public key is really yours

• Hand out the form to a WWUCA team member, presenting an official proof of identity
  (identity card or passport, no driving license, no student card)

• The WWUCA never sees your private key (is no »trust center«)

Keeping your private key safe

• Beneath all usual measures to protect computer and password

• Use dedicated browser instance / virtual machine for sensitive applications

• Always protect your private key by encrypting with a password resp. PIN
  (Firefox: Set master password before key generation, always encrypt PKCS#12 backup files with a password!)

• Always encrypt the medium containing your private key, too.

• For authentication purposes, better use hardware device (smartcard, eToken, nPA) with a PIN.

  • But do think twice for e-mail purposes: you cannot read old e-mails any longer if you loose a your private key

• Always keep in mind: Your private key is only needed when signing and when decrypting, never else.

• Get paranoid. Even more paranoid. “Social Engeneering” is the most successful way of attacking.

What is a certification hierarchy?

What is our certification hierarchy?

Certification hierarchy

• The certificate of Rainer Perske is signed by the Zertifizierungsstelle der Universität Münster
  (WWU Certification Authority, WWUCA)

• The WWUCA is an intermediate CA because ...

• The certificate of the WWUCA is signed by the DFN Public Key Infrastructure (DFN-PKI) “Global” CA
  (DFN = Deutsches Forschungsnetz = German Research Network)

• The DFN-PKI “Global” CA is an intermediate CA because ...

• The certificate of the DFN-PKI “Global” CA is signed by the “Deutsche Telekom Root CA 2”

• The “Deutsche Telekom Root CA 2” is a root CA because ...

• The certificate of the “Deutsche Telekom Root CA 2” is signed by itself.

Rainer Perske   ⇐   WWUCA   ⇐   DFN-PKI “Global” CA   ⇐   Deutsche Telekom Root CA 2

Why DFN-PKI “Global”?

• The “Deutsche Telekom Root CA 2” certificate is part of nearly all browsers and e-mail programs

• Intermediate CAs inherit the trust set in the root CA

• Thus nearly all e-mail programs can check our e-mail signatures automatically
  and all browsers accept our server certificates automatically

• Recipients of our e-mails or users connecting to our servers do not receive boring warnings

• Demo: Firefox: Edit the CA certificate of “Deutsche Telekom Root CA 2”

WWUCA

• 4 staff members (at ZIV) + 5 further team members (spread over WWU and UKM)

• I spend about 10 % of my time for the WWUCA, all others far less.

• X.509 certificates issued by the WWUCA (all in the DFN-PKI “Global” hierarchy):

  year	total	server	user	group	code	intern	(revoc's)
  2014	499	332	148	9	4	6	(97)
  2013	366	177	177	4	3	5	(45)
  2013	366	177	177	4	3	5	(45)
  2012	295	113	160	1	3	8	(91)
  2011	305	80	214	3	1	7	(36)
  2010	208	103	94	0	9	2	(14)
  2009	159	69	87	0	0	3	(20)
  2008	265	166	96	1	0	2	(92)
  2007	307	159	136	1	2	9	(18)

• 2014: Heartbleed (OpenSSL bug), SHA-1 deprecation, Poodle (SSLv3 bug)

• 2014 numbers as on Nov. 25^th – Still expected: those for you + others ⇒ ca. 600 total

• OpenPGP discontinued after 2011: Less than 15 requests per year

DFN PKI

• Service of the German Research Network provided by DFN CERT GmbH in Hamburg
  (CERT = Computer Emergency Response Team)

• DFN-PKI team (8 members) operates and develops the DFN-PKI

  • 5 X.509 hierarchies with different policies (“Classic”, “Global”, “Basic”, “Grid”, “SLCS”)

  • 370 outsourced subordinate CAs of DFN e.V. members (incl. WWUCA)

  • OpenPGP discontinued due to lack of demand

• No additional costs: DFN PKI service is part of the DFN Internet service

  • WWU + UKM + KA + FH + MPI together pay 250.000 €/a for 2×5 GBit/s cluster connectivity

DFN PKI hierarchies

• DFN-PKI “Global” (sub-CA of Deutsche Telekom Root CA 2)
  highest available security, approved by all market leaders
  WWUCA is working in this hierarchy.

• DFN-PKI “Classic” (root CA)
  same security, but not approved by market leaders
  was replaced by “Global” as soon as available (2007)

• DFN-PKI “Basic” (root CA)
  relaxed requirements for identity control
  not supported by WWUCA (all identification methods available to the WWUCA that fulfil the “Basic” requirements also fulfil the “Global” requirements.)

• DFN-PKI “Grid” (root CA, for scientific grid computing, acknowledged by the EUGridPMA)
  has no subordinate CAs but I am (was) registrar (last request was in 2012)

• DFN-PKI “SLCS“ (root CA, Short-Lived Credential Service)
  not supported by WWUCA due to lack of demand

• OpenPGP (not a hierarchy but a web of trust)
  discontinued by DFN after 2009 due to lack of demand
  WWUCA continued service until 2011

How does the WWUCA issue a certificate?

What requirements must be met?

Certification process (1)

• The WWUCA team member:

  • strictly obeys Certificate Policy (CP) and Certification Practice Statement (CPS)
    (Rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc.)
    CP: https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CP.pdf
    CPS: https://www.pki.dfn.de/fileadmin/PKI/DFN-PKI_CPS.pdf

  • checks all aspects of your request (perhaps applies corrections or rejects)

  • adds some data (Subject Alternative Names): e-mail addresses, login name, ...

  • compares the fingerprint on the form with that of the public key
    (thus the WWUCA knows the public key with the given fingerprint is yours)

  • (electronically) signs a confirmation message to the certification server

  • (manually) signs and archives your request form

Certification process (2)

• The DFN PKI certification server in Hamburg automatically:

  • checks the signature of the message and the accreditation of the signer

  • checks conformance of the request (only our domains? etc.)

  • creates the certificate

  • mails the certificate to the requester

  • publishes the certificate via LDAP (if requested)

    • Use as addressbook: ldap.pca.dfn.de:389, Base-DN: O=DFN-Verein,C=DE

    • Thunderbird: Bearbeiten | Einstellungen | Verfassen | Adressieren | LDAP-Verzeichnisserver | Bearbeiten | Hinzufügen ...

X.500 DNs in WWUCA certificates

• Several restrictions by CP+CPS (most of them technically enforced by DFN PKI):

• only servers and e-mail addresses belonging to WWU, UKM, or KA

• emailAddress=. . . (only for users, at most one, but see below)
  CN=. . . (exactly one must be given; only name parts from identity card, no “Prof.“ or alike)
  OU=. . . (at most one may be given, avoid abbreviations)
  O=Universitaet Muenster (or) O=Universitaetsklinikum Muenster (or) O=Kunstakademie Muenster (must be given)
  L=Muenster (and) ST=Nordrhein-Westfalen (optional for users; must be given for servers)
  C=DE (must be given)

• Limited character set for CN/OU/O/L/ST/C: a-z A-Z 0-9 '()+,-./:=? space; limited field length (64)
  Convert german letters: ä ö ü ß Ä Ö Ü ⇒ ae oe ue ss Ae Oe Ue,
  Remove accents: Ibáñez ⇒ Ibanez, Łódź ⇒ Lodz
  Phonetically transcribe other scripts: Δήμητρα ⇒ Dimitra, Ærøskøbing ⇒ Aeroeskoebing

• Order matters and no other fields allowed

• E-mail addresses, login names etc. can be given als Subject Alternative Name, but must be verified

How do you use a certificate?

When do you use a certificate?

Presenting a certificate

• You present your certificate (and all intermediate certificates):

  • As a person/group: when sending a signed e-mail (attached to the signature)

    • The recipient will check signature and certificate

  • As a server: when accepting an HTTPS (IMAPS, POP3S, ...) connection

    • The client will check the certificate and compare the host name

  • As a client: when connecting to an HTTPS (IMAPS, POP3S, ...) server

    • Only if expected by the server (better security than password authentification)

    • The server will check the certificate

    • Try: https://xsso.uni-muenster.de/MeinZIV/

Verifying a certificate

• For checking certificates you need the corresponding root certificate

• Many root certificates are pre-installed in your software, but can be edited

  • The CA/Browser Forum recommends requirements for CAs whose root certificates are built in

• Verifying certificates = (automatically)

  • comparing identity in certificate with e-mail partner resp. hostname

    • Hosts and domains are case-insensitive but local parts of e-mail addresses are case-sensitive:
      perske@wwu.de   =   perske@WWU.DE   ≠   Perske@WWU.DE

    • Always use lowercase only, both in certificates and in your e-mail configuration

  • checking all ( signature + purpose + life time + more ) of each certificate involved

  • checking trust in root certificate

  • checking whether the certificates make up a complete certificate chain

• Demo: Firefox: https://www.uni-muenster.de/ | padlock symbol | Show certificates | Details

How do you become a root CA yourself?

How do you become a serious root CA yourself?

How to become a root CA

• Use OpenSSL: www.openssl.org

• Set up a complete root CA:
  mkdir demoCA demoCA/newcerts
  touch demoCA/index.txt
  echo 01 >demoCA/serial
  openssl req -x509 -newkey rsa:2048 -out CA.crt -keyout CA.key
  openssl x509 -in CA.crt -noout -text

• By client: create a key pair and a request:
  openssl req -new -nodes -out XY.req -keyout XY.key

• By CA: create certificate:
  openssl ca -days 10 -keyfile CA.key -cert CA.crt -in XY.req -out XY.crt
  openssl x509 -in XY.crt -noout -text

How to become a serious root CA

• Set up a policy with rules for security, target audience, privacy, methods, archiving, contents, life times, revocations etc. you declare to obey strictly

• Announce yourself to the browser makers (for Mozilla use Bugzilla)

• Example: Deutsche Telekom Root CA 2: https://bugzilla.mozilla.org/show_bug.cgi?id=378882

  • Request sent: April 2007; integration in Firefox+Thunderbird: July 2009

  • Rigorous checking of requirements (policies, audits etc.) over months and years

  • Requesting CA has to adapt every little bit of its policy and its operation to the requirements

• Leading party in the ongoing development is the CA/Browser Forum: https://cabforum.org/

  • Most of our policy changes in the last years came due to new CA/Browser Forum requirements

• It costs millions of Euros to operate a CA that meets all requirements:

  • All universities delegate CA operation to DFN and DFN cooperates with Telekom

• We don't want to trust “Honest Achmed”: https://bugzilla.mozilla.org/show_bug.cgi?id=647959

  • Serious background: blunders of Commodo, DigiNotaar and others

Thank you

• Rainer Perske

• Westfälische Wilhelms-Universität
  Zentrum für Informationsverarbeitung
  Zertifizierungsstelle
  Röntgenstraße 7-13
  48149 Münster

• ca@uni-muenster.de
  +49 251 83 31590 (fon)
  +49 251 83 31555 (fax)

© 2011-2014 Rainer Perske und Universität Münster