1. Install EJBCA as described here
2. Log in as Admin (https://ca.example.com:8443/ejbca) and set up a ROOT Certificate Authority.
The idea is to create a root certificate that would be accepted by the latest Microsoft and Mozilla root CA programmes (details to be found here and here).
As I have not obtained the necessary information, I would appreciate your contributions and corrections in the necssary/missing sections. You can contact me via ws2016 at bluhm-de dot com.
Administration -> CA Functions -> Edit Certificate Profiles -> ROOTCA (fixed)
Enter a new name in the "Add Profile" text box (like Custom ROOT CA Profile) and click "Use selected as template"
Reason to create an own template is to always be aware of the chosen options, should the default/fixed EJBCA profile change in an update.
Highlight the newly created profile and click on "Edit Certificate Profile" and change the fields according to this:
Available bit length: 8192 bits
Signature Algorithm: SHA256withECDSA
Validity: 20y
Permissions - Allow all
Extended Key Usage: Use
Select All but Any Extended Key usage
I am not sure if any are really required for the root certificate. According to the Mozilla CA Certificate Inclusion Policy, they expect that in the root though (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/)
CRL Distribution Points: Use
Use CA defined CRL Dist. Point - TODO
CRL Distribution Point URI - TODO
CRL Issuer - TODO
Certificate Policies - TODO. Is this required for the Microsoft programme?
OCSP - TODO
3. Set up a Sub Certificate Authority
X509
TestRoot "C=SE,O=PrimeKey,CN=TestRoot" soft foo123 2048 RSA 365 --policy 2.5.29.32.0 SHA256WithRSA
A. Root Requirements
The CN attribute must identify the publisher and must be unique.
The CN attribute must be in a language that is appropriate for the CA’s market and readable by a typical customer in that market.
Basic Constraints extension: must be cA=true.
Key Usage (if present) must be keyCertSign and cRLSign only.
Root Key Sizes must meet the requirements detailed in “Key Requirements”.
New roots must be valid 8-25
The CA may not issue new 4096 bit RSA certificates.
All certificates issued from a root certificate must support either the CRL distribution point extension or AIA containing an OCSP responder URL
Private Keys and subject names must be unique per root certificate; reuse of private keys or subject names in subsequent root certificates by the same CA may result in random certificate chaining issues. CAs must generate a new key and apply a new subject name when generating a new root certificate prior to distribution by Microsoft.
Rollover root certificates, or certificates which are intended to replace previously enrolled but expired certificates, will not be accepted if they combine server authentication with code signing uses unless the uses are separated by application of Extended Key Uses (“EKU”s) at the intermediate CA certificate level that are reflected in the whole certificate chain.
Intermediate CA certificates must meet the requirements for algorithm type and key size for Subordinate CA certificates listed in Appendix A of the CAB Forum Baseline Requirements, which can be found at https://www.cabforum.org.
Intermediate CA certificates under root certificates submitted for distribution by the Program must separate Server Authentication Code Signing and Time Stamping uses. This means that a single issuing CA must not be used to issue both server authentication and code signing certificates. A separate CA must be used for each use case.
End-entity certificates must meet the requirements for algorithm type and key size for Subscriber certificates listed in Appendix A of the CAB Forum Baseline Requirements.
For Server Authentication certificates, Windows will stop trusting SHA1 certificates on 1 January 2017. This means any SHA1 SSL certificates issued before or after this announcement must be replaced with a SHA2 equivalent by January 1, 2017.
CAs must use the following OIDs in the end-entity certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2; EV 2.23.140.1.1.; IV 2.23.140.1.2.3; EV Code Signing 2.23.140.1.3; Non-EV Code Signing 2.23.140.1.4.
End-entity certificates that include a Basic Constraints extension in accordance with IETF RFC 5280 must have the cA field set to FALSE and the pathLenConstraint field must be absent.
CA Functions -> Edit Certificate Authorities
Add CA -> "Example Root CA" as the name of new certification authority -_> Create
Digest Algorithms SHA2 (SHA256, SHA384, SHA512)
RSA 4096
ECC/ECDSA NIST P-256, P-384, P-521
According to Microsoft Root Program requirements, these are the specs (Source:
https://technet.microsoft.com/en-us/library/cc751157.aspx?f=255&MSPPError=-2147217396 )
- The policy OID that the CA will use to identify kernel-mode code signing.
- Microsoft will only enable the following EKUs:
Server Authentication =1.3.6.1.5.5.7.3.1
Client Authentication =1.3.6.1.5.5.7.3.2
Secure E-mail EKU=1.3.6.1.5.5.7.3.4
Code Signing EKU=1.3.6.1.5.5.7.3.3
Time stamping EKU=1.3.6.1.5.5.7.3.8
Encrypting File System EKU=1.3.6.1.4.1.311.10.3.4
Document Signing EKU=1.3.6.1.4.1.311.10.3.12
Server Authentication certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust certificates signed with SHA-1 after January 1, 2017.
Code signing certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Windows Server 2008 CAs will be allowed to continue issuing SHA-1 certificates.
Time-stamping certificates: CAs must begin issuing new certificates using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Windows Server 2008, CAs will be allowed to continue issuing SHA-1 certificates. Windows will not enforce a policy on time-stamping certificates.
OCSP signatures: Microsoft requires CAs to start issuing new OCSP signatures using only the SHA-2 algorithm after January 1, 2016. Windows will no longer trust OCSP responses that use SHA-1 for their signature if the corresponding certificate had the Must Staple extension after January 1, 2016
Time-stamp signature hashes: CAs must start issuing new time-stamp signature hashes using only the SHA-2 algorithm after January 1, 2016. For developers targeting Windows Vista and Server 2008, CAs will be allowed to continue issuing SHA-1 time-stamps.
C. Revocation Requirements
CAs that issue Server Authentication certificates must support the following OCSP responder requirements:
Minimum validity of 1 day; Maximum validity of 1 week; and
The next update must be available at an interval of ½ of the validity period. For example, if the maximum validity is 48 hours the next update must be available 24 hours before the current item expires.
All certificates issued from a root certificate must support either the CRL distribution point and/or AIA containing an OCSP responder URL.
The CA must not use the root certificate to issue end-entity certificates.
The CA must operate their own Time Stamp Authority. The Time Stamp Authority must comply with RFC 3161, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).”
Signing Algorithm: SHA256WithRSA
RSA key size: 4096
Description: Root CA for Example Inc.
Validity (*y *mo *d) or end date of the certificate: 20y
Subject DN: CN=Example Root CA,O=Example Inc.,C=RS
Use Issuing Distribution Point on CRLs: On
Default CRL Dist. Point: http://crl.example.com/rootca.crl
CRL Expire Period (*y *mo *d *h *m): 1y
CRL Overlap Time (*y *mo *d *h *m): 2d
SubCA
Field explanations can be found here: http://wiki.ejbca.org/editcas
Type of CA: X509
CA Token Type: Soft
Authentication Code: Enter a custom code (custom code is preferred for enhanced security and portability)
Enable auto-activation of CA token: De-Activate. Ideally you not not want to start up the Root CA if you are not using it for signing. If you activate the box, the password is stored on the server and available for compromise.
Signing Algorithm: SHA512withRSA
RSA key size: 8192
DSA key size: 1024 (cannot be changed)
ECDSA key spec: blank (not in use)
Key sequence format: (not in use)
Key sequence: (not in use)
Description: Enter something useful here (like where you stored the master passwords)
Directives
Enforce unique public keys: Enforce
Enforce unique DN: Enforce
Enforce unique Subject DN SerialNumber: Enforce
Use Certificate Request History: Use
Use User Storage: Use
Use Certificate Storage: Use
CA certificate data
Validity (*y *mo *d) or end date of the certificate [?]
ISO 8601 date: [yyyy-MM-dd HH:mm:ssZZ]: '2016-04-30 20:53:56+02:00'
Subject DN
Signed By
Certificate Profile
Subject Alternative Name
Certificate Policy Id
(leave policy id blank to use default certificate profile values)
Use UTF-8 in policy notice text Use
PrintableString encoding in DN Use
LDAP DN order [?] Use
CRL Specific Data
Authority Key ID Use Critical
CRL Number Use Critical
Issuing Distribution Point on CRLs Use Critical
Default CRL Dist. Point [?]
(used as default value in certificate profiles using this CA)
Default CRL Issuer [?]
CA Defined FreshestCRL extension [?]
(used as default value in certificate profiles using this CA)
CRL Expire Period (*y *mo *d *h *m) [?] y=365 days, mo=30 days
CRL Issue Interval (*y *mo *d *h *m) [?] y=365 days, mo=30 days
CRL Overlap Time (*y *mo *d *h *m) [?] y=365 days, mo=30 days
Delta CRL Period (*y *mo *d *h *m) [?] y=365 days, mo=30 days
(0m, if no delta CRLs are issued)
Publishers
Services
Default OCSP Service Locator [?]
(used as default value in certificate profiles using this CA)
OCSP Service Activate
CMS Service Activate
Other data
Approval Settings
Number of Required Approvals
Finish User [?] Use
CMP RA Authentication Secret [?]