VA DELEGATED TRUST MODEL Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 1
TABLE OF CONTENTS OVERVIEW:... 3 SALIENT FEATURES:... 3 BENEFITS:... 4 DRAWBACKS:... 4 MIGRATION FROM DIRECT TRUST MODEL:... 5 MIGRATION TO CA-DELEGATED TRUST MODEL:... 5 INSTALLING THE DELEGATED MODEL WITH VCOPENSSL:... 6 Setting up vcopenssl environment:... 6 Issuing Root VA OCSP Response/ Certificate / CRL signing certificate:... 7 To generate CRLs off the Root VA:... 15 Issuing Root VA / L1 VA SSL Certificates:... 17 Issuing L1VA OCSP Response Signing Certificates:... 22 Revoking certificates issued by the Root VA:... 26 Configuring Desktop Validator for the VA-delegated trust model:... 29 Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 2
VA-delegated Trust Model Overview: This document is to outline the specifics of the VA-delegated model, and discuss its merits and disadvantages when compared to the direct trust and the CA-delegated models. Details on migrating to and from this trust model are also described. Salient features: ROOT VA CA1 CA2 CA3 LEVEL 1 VA1 LEVEL 1 VA2 LEVEL 1 VA3 Certificate Issuance Desktop/Server Validator CRL Issuance Authority Information Access [AIA] OCSP request/response 1. Root VA has a self-signed OCSP-signing certificate with the following attributes: a. Key Usage set to Certificate and CRL signing b. Extended Key Usage set to OCSP Signing c. OCSPNoCheck extension Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 3
2. All other VA certificates are issued off this self-signed certificate, and have the following attributes: a. Extended Key Usage set to OCSP Signing [for OCSP signing certificates] b. Key Usage set to Key Encipherment [for SSL server certificates] c. Authority Information Access [AIA] set to URL of the Root VA [multiple URLs may be present, for fail-over scenarios] 3. Client applications, such as the desktop and server validators are either configured for CA-specific validation [different VAs for different CAs] or default validation [single source of revocation information across all CAs]. In addition, they are configured to validate responder certificate in delegated mode, by either following the AIA in the responder certificate, or setting CAspecific validation options for the Root VA. 4. The Root VA OCSP signing certificate is the only certificate that needs to be explicitly trusted by the client applications. Benefits: 1. Eliminates dependence on OCSP-issuance policies at CA 2. End-to-end OCSP solution better performance than hybrid of OCSP and CRL checking which is needed for CA-delegated trust model 3. Mirroring of Root VA information to other VAs possible, to account for fault-tolerance clients [such as the Valicert DV/SV] have the capability to go iteratively through a list of AIAs [if present] in the VA certificates. 4. Instant revocation of rogue L1 VAs at Root VA ensures timely dissemination of VA status to clients 5. No re-keying necessary easy migration to/from either direct trust or CA-delegated trust Drawbacks: 1. The VA does not provide an administration GUI to issue delegated certificates to other [level 1] VAs. As such, this can be done using openssl [shipped as part of the VA software distribution], or vcopenssl - Valicert-customized version of openssl that includes support for key generation on HSMs like ncipher and Chrysalis. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 4
Migration from direct trust model: 1. VA needs the following keys: a. Mandatory: default.cert used to sign OCSP responses to clients b. Optional: sslcert.cert used for SSL communication, if configured c. Optional: crlsigning.cert used to sign CRL mirroring queries/responses, if configured d. Optional: cmpadmin.cert used by the Admin to sign CMP requests for instant revocation, if configured In the direct trust model, these certificates are usually self-signed. When generating these keys, the VA will also store certificate requests [CSRs] corresponding to each key pair: cacrl.req, ssl.req, crlsigning.req, cmpadmin.req 2. Though only cacrl.req is necessary, the other requests can also be re-certified by the Root VA s OCSP signing key. 3. Drop in the new, Root VA-issued certificates after backing up the existing versions. 4. Restart the VA service from the administration GUI, the services panel [Windows only] or vactl [Solaris only] 5. Reconfigure all the clients to trust only the Root VA s OCSP signing certificate for signature verification of responses from the L1 VAs, and to validate the VA certificates in delegated mode. Clients will follow AIA to Root VA to validate L1 VA certificates. Migration to CA-delegated trust model: 1. VA s existing request files [of which only cacrl.req is mandatory] can be re-certified as per the DOD s OCSP certificate issuance policy no new keys need to be generated. 2. Drop in the new CA-issued certificates after backing up the existing VA-issued versions. 3. Restart the VA service from the administration GUI, the services panel [Windows only] or vactl [Solaris only] Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 5
4. Reconfigure all the clients to trust only the OCSP CA certificate, and to validate the VA certificates in delegated mode. Clients can be configured to follow the CRLdp extension on the VA certificates to validate them. Installing the delegated model with vcopenssl: vcopenssl is a utility developed by Valicert that wraps a PKCS11 layer around openssl to interface with HSMs [ncipher, Chrysalis, Baltimore, Eracom etc.] for functions like key generation and certification. vcopenssl is used at the Root VA to issue OCSP/SSL certificates to L1VAs, revoke VA certificates and generate CRLs. The instructions below assume that the Root VA will be using an ncipher HSM. vcopenssl can also be used with software keys. Setting up vcopenssl environment: All requests that are to be certified by the Root VA, will be copied to this location and certified. Issued certificates will then be imported back by the requesting party. On the Root VA installation machine, open up a DOS prompt: 1. mkdir delegatedtrust ## Base dir to run vcopenssl commands 2. cd delegatedtrust 3. copy vcopenssl into delegatedtrust 4. copy config files [rootva.cnf,l1va.cnf,vassl.cnf] to delegatedtrust 5. The following lines are important in the openssl configuration files, and can be modified, if needed, to meet your requirements: dir =./rootva new_certs_dir = $dir/newcerts database = $dir/rootvaindex.txt certificate = $dir/rootva.cert serial = $dir/rootva.srl x509_extensions = x509v3_extensions crl_extensions = crl_extension_section **Assuming you want to use the parameters specified above** 6. mkdir rootva Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 6
7. cd rootva 8. Create file rootva.srl 9. Open rootva.srl in a text editor like notepad and insert "01" to the beginning of the file ## 01 - starting serial number for issued certs 10. Create an empty file rootvaindex.txt ## Database containing information for all certs issued by the Root VA 11. mkdir newcerts Issuing Root VA OCSP Response/ Certificate / CRL signing certificate: The Root VA will issue a self-signed certificate to itself with the OCSP NoCheck extension, and with key usages set for CRL and certificate signing. The key will be generated on the ncipher HSM and this key will then be used to issue certificates to other entities in the model. 1. The following lines in rootva.cnf file are of importance: [ x509v3_extensions ] crldistributionpoints basicconstraints keyusage = URI:http://crlserver:105/rootva.crl = critical, CA:TRUE = critical, keycertsign, crlsign, digitalsignature, nonrepudiation extendedkeyusage = critical, serverauth, 1.3.6.1.5.5.7.3.9 ## OCSP Signing 1.3.6.1.5.5.7.48.1.5 = DER:16:0C:4F:43:53:50:20:4E:6F:43:68:65:63:6B ## OCSP NoCheck subjectkeyidentifier = hash authoritykeyidentifier = keyid,issuer authorityinfoaccess = OCSP;URI:http://primaryva:2000, OCSP;URI:http://secondaryva:2000 2. Copy rootva.cnf as <VAInstallDir>/openssl/lib/openssl.cnf - backup the existing version of openssl.cnf to openssl.cnf.org 3. Use EVA GUI to generate a new OCSP response signing key and self-signed certificate. Use ncipher as the key generation mechanism. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 7
Manage Keys and Certificates -> Generate New Private Key -> signing OCSP responses Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 8
Successfully created self-signed certificate Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 9
4. This self-signed certificate can be imported into CAPI and server trust databases on client machines. To download the certificate from the EVA GUI, click on: Manage Keys and Certificates -> Download VA Certificate -> Save the file to disk Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 10
To import the certificate into CAPI, use IE to open the saved certificate file and click on Install Certificate to bring up the Certificate Import Wizard. Select Place all certificates in the following store and add the certificate to Local Computer in Trusted Root Certification Authorities. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 11
Open up the certificate with IE to view the extensions that are part of this certificate. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 12
OCSP NoCheck extension on the Root VA certificate 5. Copy this certificate [<ROOTVAInstallDir>/entserv/default.cert] to delegatedtrust/rootva/rootva.cert. 6. If you will be issuing other self-signed certificates at the Root VA [for SSL, CRL signing etc] move back openssl.cnf.org to openssl.cnf Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 13
7. Add the OCSP signing certificate as a trusted CA for the Root VA: Manage Keys and Certificates -> View Certificate -> signing OCSP responses to copy the contents of the base64-encoded certificate. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 14
Manage Certificate Stores -> Add Certificate -> "Certificates of CAs publishing CRLs to the VA" to add the OCSP signing certificate as a trusted CA publishing CRLs to the Root VA. This will enable the Root VA to validate certificates issued off it [L1 VA certificates] To generate CRLs off the Root VA: The Root VA can be used to generate CRLs that may contain information about revoked L1VAs. vcopenssl can be used to generate CRLs on the command line. 1. Open up a DOS prompt, and navigate to the delegatedtrust directory 2. Run the following command: where, vcopenssl vcca -config rootva.cnf -gencrl -engine vcengine -vendorid 2 -slotid 1 Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 15
-config -gencrl -engine -vendorid -slotid - configuration file containing extensions to be present in the issued CRL - tells vcopenssl to generate a new CRL based on local configuration information - PKCS11 layer to HSM - numeric ID of the vendor [2 => ncipher] - Slot ID to use [-1 => autosense] on HSM This will prompt the administrator to enter the password protecting the ncipher OCS. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 16
3. Save the output to crl.pem and run the following command to convert the CRL to DER-encoded format: vcopenssl crl -outform DER -in crl.pem -out crl.crl Use IE to open the CRL and view its contents 4. This CRL can be pushed to Root VA via the Valicert VA Publisher. Issuing Root VA / L1 VA SSL Certificates: In addition to issuing L1VA OCSP signing certificates, the Root VA can also be used to issue SSL certificates to itself and L1VAs. This would facilitate SSL server authentication for clients such as the Valicert Desktop and Server Validators. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 17
1. The following lines in vassl.cnf are of importance: [ x509v3_extensions ] crldistributionpoints = URI:http://crlserver:105/rootva.crl basicconstraints = critical, CA:FALSE keyusage = critical, keyencipherment, dataencipherment, keyagreement extendedkeyusage = critical, serverauth subjectkeyidentifier = hash authoritykeyidentifier = keyid,issuer authorityinfoaccess = OCSP;URI:http://primaryva:2000 OCSP;URI:http://secondaryva:2000 2. Use EVA GUI to generate new SSL signing CSR. Use ncipher as the key generation mechanism. Manage Keys and Certificates -> Generate New Private Key -> SSL communication with clients (Optional) ** If already generated, it is not necessary to generate a new key** Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 18
3. Copy SSL CSR [<VAInstallDir>/entserv/ssl.req] as rootvassl.req [or l1vassl.req] into delegatedtrust on the Root VA machine. The request file can be extracted from the EVA GUI: Manage Keys and Certificates -> Display Certificate Request -> SSL communication with clients (Optional) 4. To issue the SSL certificate off the Root VA OCSP certificate, run the following command from delegatedtrust on the Root VA: vcopenssl vcca -engine vcengine -config vassl.cnf -days 1825 - extensions x509v3_extensions -vendorid 2 -slotid -1 -in rootvassl.req where, -engine - PKCS11 layer to HSM -config - config file containing extensions to be inserted into issued certificate -days - number of days to certify the certificate for -extensions - Extension section in config file -vendorid - numeric ID of the vendor [2 => ncipher] -slotid - Slot ID to use [-1 => autosense] on HSM Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 19
-in - input certificate request Hit y to issue the certificate off the Root VA. The new certificate will be stored in the newcerts directory under rootva in delegatedtrust on the Root VA. 5. Copy base64-encoded certificate [-----BEGIN CERTIFICATE-----...- ----END CERTIFICATE-----] in rootva/newcerts/01.pem [serial # of issued certificate] as <VAInstallDir>/entserv/sslCert.cert on RootVA/L1VA installation. This can also be done via the EVA GUI: Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 20
Manage Certificates -> Add Certificate -> Certificate for SSL communication with clients (Optional) Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 21
You can use IE to view the contents of the issued SSL certificate. Issuing L1VA OCSP Response Signing Certificates: L1VA OCSP response signing certificates are issued the same way as SSL certificates, but off a different configuration file to insert the OCSP signing extension. 1. The following lines in l1vaocsp.cnf are of importance: [ x509v3_extensions ] crldistributionpoints = URI:http://crlserver:105/rootva.crl basicconstraints = critical, CA:FALSE keyusage = critical, digitalsignature, nonrepudiation extendedkeyusage = critical, serverauth, 1.3.6.1.5.5.7.3.9 ## OCSP Signing Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 22
subjectkeyidentifier authoritykeyidentifier authorityinfoaccess = hash = keyid,issuer = OCSP;URI:http://primaryva:2000, = OCSP;URI:http://secondaryva:2000 2. Use EVA GUI to generate new OCSP signing CSR. use ncipher as the key generation mechanism: Manage Keys and Certificates -> Generate New Private Key -> signing OCSP responses ** If already generated, it is not necessary to generate a new key** Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 23
3. Copy OCSP CSR [<VAInstallDir>/entserv/cacrl.req] as l1va.req into delegatedtrust on the Root VA machine. This can also be done via the EVA Admin GUI: 4. To issue the L1OCSP certificate off the Root VA OCSP response signing certificate, run the following command from delegatedtrust on the Root VA: vcopenssl vcca -engine vcengine -config l1vaocsp.cnf -days 1825 -extensions x509v3_extensions -vendorid 2 -slotid -1 -in l1va.req where, -engine - PKCS11 layer to HSM -config - config file containing extensions to be inserted into issued certificate -days - number of days to certify the certificate for -extensions - Extension section in config file -vendorid - numeric ID of the vendor [2 => ncipher] -slotid - Slot ID to use [-1 => autosense] on HSM -in - input certificate request Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 24
Hit y to issue the certificate off the Root VA. The new certificate will be stored in the newcerts directory under rootva in delegatedtrust on the Root VA. 5. Copy base64-encoded certificate [-----BEGIN CERTIFICATE-----...- ----END CERTIFICATE-----] in rootva/newcerts/02.pem [serial # of issued certificate] as <L1VAInstallDir>/entserv/default.cert. This can also be done via the EVA Admin GUI: Manage Certificates -> Add Certificate -> Certificate for signing OCSP responses Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 25
To view the issued certificate, click on Manage Keys and Certificates -> Download VA certificate -> open : Revoking certificates issued by the Root VA: The Root VA can be used to revoke L1VA certificates, should the need arise. This can be done in two ways: 1. Use instant revocation on the Root VA to revoke any certificate issued by the VA by specifying a serial number. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 26
Manage CRLs -> Revoke Certificate 2. Use vcopenssl on the command line to revoke a certificate by presenting the certificate itself. From delegatedtrust on the Root VA, run: vcopenssl vcca -config rootva.cnf -revoke rootva\newcerts\02.pem -engine vcengine -vendorid 2 -slotid 1 where, -config -vendorid -slotid -engine -revoke - config file containing extensions to be inserted into issued certificate - numeric ID of the vendor [2 => ncipher] - Slot ID to use [-1 => autosense] on HSM - PKCS11 layer to HSM - revoke the specified certificate Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 27
In this case, a new CRL can be issued which will have the revoked entry information: Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 28
Configuring Desktop Validator for the VA-delegated trust model: To import the certificate into CAPI, use IE to open the saved certificate file and click on Install Certificate to bring up the Certificate Import Wizard. Select Place all certificates in the following store and add the certificate to Local Computer in Trusted Root Certification Authorities. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 29
To configure DV to trust the Root VA, and not the L1VA OCSP responder directly, bring up the control panel applet click on default/ca-specific validation options: Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 30
Select the L1VA responder and hit click on Edit to change the trust model: Instead of autoconfig, select Choose to select the Root VA certificate: Restart all DV-enabled applications for the change to take effect. Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 31
To configure DV to validate the L1VA responder, bring up the control panel applet, and click on the Validation tab: Select the Validate responder certificate in delegated mode checkbox, and restart all DV-enabled applications for changes to take effect. This will force DV to make an extra validation check for the status of the L1VA responder certificate. DV can validate the L1VA certificate if: 1. Configured to Follow Authority Information Access [AIA] extension on the L1VA certificate this can be set on the Validation tab of the DV control panel applet; or Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 32
2. CA-specific validation options are set for the Root VA OCSP certificate that is present in CAPI: FOR MORE INFORMATION, PLEASE CALL 650.216.2121 Tumbleweed Communications Corp 700 Saginaw Drive Redwood City, CA 94063 Phone 650.216.2000 Fax 650.216.2001 www.tumbleweed.com info@tumbleweed.com 2004 Tumbleweed Communications Corp. All rights reserved. Tumbleweed is a registered trademark and Tumbleweed Validation Authority, Tumbleweed Desktop Validator are trademarks of Tumbleweed Communications Corp. All other brand names are the trademarks of their respective owners. STFWP0304 Copyright 2004 Tumbleweed Communication Corp. All Rights Reserved. 33