This repository contains scripts meant to make managing an openssl ca less painful inside a terminal environment
Before running create_ca.sh
, it is probably a good idea to set some defaults. You do
that by editing a file called ca_presets.ini.
This file has to reside in the current directory. Its format is key="value"
. The double quotes can be
omitted if the value does not contain spaces. Allowed keys at this time are:
A template for this file can be generated by calling create_ca.sh
with command line
switch -g
.
After starting create_ca.sh
, you are asked first for the type of the CA. the available types are
fetched from the templates. an example for the choices available may look like this:
The next step is to enter the name of the CA. This is at the same time the name of the directory all files belonging to this new CA are put into. So make sure there is no file or directory with this name in the current directory. Also do not use the following names:
After that, the script asks for the URL of the associated OCSP responder. If you do not want or have one, just leave that field blank - otherwise, you must enter a valid URL for accessing the responder here!
Now, the script shows the information read from ca_presets.ini (if applicable):
And the user can afterwards change / enter the Distinguishes Name for the CA:
The next step is the specification of the key length if neither options -e
nor -s
are given
(option -l
also would skip this step):
If option -e
is given, the next step allows to choose a supported parameter set for the elliptic
curve private key (option -s
would skip this step):
and the hash or message digest algorithm:
Now, the script informs you about the possibilities to enter default values for Certificate Signing Requests (CSRs). Each CA offers different flavours of certificates it can issue. For each of these, the script generates a config file to facilitate the creation of CSRs. And each of these config files can have default values set for the fields inside the distinguished name. Setting default values makes it a little easier and more convenient for end entities to create CSRs.
It is not necessary to specify such defaults for all flavours - you can choose which ones you want:
If you choose at least one - a dialog like this one here is displayed to enter the default values:
Afterwards, you are informed that you can specify Certificate Policy Statements (CPSs) for each flavour:
It is not necessary to specify CPSs for all flavours - you can choose which ones you want:
If you choose at least one - a dialog like this one here is displayed to let you enter the information for each CPS:
The next step is to define any custom OIDs you want to use while working with this new CA. You are informed about that possibility like so:
The dialog for entering identifier, OID and description is repeatedly shown as long as all three fields are filled - giving you the opportunity to enter an arbitrary number of custom OIDs. The script does not allow to re-use an already entered identifier or OID:
Now, you have to enter a password to protect the private key of the CA:
The next step is to specify the location for the log:
Then, the certificate signing request is displayed:
And that concludes the process - the script shows some informational messages to wrap it all up:
After a CA is created, there are several possibilities to customize it further.
But first - a warning!
The scripts inside this document create sensible, syntactically correct configuration files for OpenSSL.
After they are created, some of those scripts read these OpenSSL config files and parse them to
extract information that is then displayed to the user inside forms and dialogs. Therefore, any
tries to cut those OpenSSL configs up into individual files and referencing them using the .include
directive is likely to render the scripts useless or to cause errors while executing them. So please - take caution
when trying to refactor the contents of the generated OpenSSL files into multiple files!
End of warning!
One good thing is to double check the configuration files in etc for any mishaps to be fixed or general changes to be made there.
This directory etc does not only hold the CAs configuration but it also
contains several configuration files that come in handy when entities want to
create Certificate Signing Requests for the CA to sign - they are created along
the CAs other files when create_ca.sh
is executed. The reason for there being more than one
is that a CA might issue different flavours of certificates according
to the intended usage scenario. For example - the Identity CA does generate
four different confguration files for creating CSRs:
encryption.conf
identity.conf
smime.conf
smime_multi.conf
Each one of these are used to create the CSR fit for the according usage scenario.
In the configuration file for the CA, one can find an extension section corresponding to the different usage scenarios - with the Identity CA again as an example, these are:
encryption_ext
identity_ext
smime_ext
These add different sets of extensions to the certificate being created.
So, if a CA admin wanted to add another usage scenario, she has to think about whether
it would be advisable to make a new client configuration available so that
the requests contain special information needed for that scenario (for example other
fields in the CN). If so, she has to provide a new client configuration. One could
use smime_multi.conf
as an example - it is a variant of smime.conf
, allowing
to use the resulting certificate for more than one email address. There is also the possibility to add
attributes to the Certificate Signing Request - the user is queried for them as she is for the
Relative Distinguished Names making up the Distinguished Name. The are sent to the CA as part of the CSR
but are not integrated into the certificate - custom extensions are (if the CA allows this). For further information
concerning non-standard extensions see the remainder of this section and also the next section.
The Distinguished Name can also be tailored exactly to the needs for the targeted use case: Possible RDNs can be found for example here. It is also possible to add custom RDNs to a DN as is shown in this example here:
[ default ]
oid_section = additional_oids
[ additional_oids ]
certificateTemplateName = 1.3.6.1.4.1.311.20.2
mySubjectAlternativeName = 1.2.3.4.5.6.7.2
myRDN = 1.2.3.4.5.6.7.3
# ... some stuff omitted for brevity ...
emailAddress = "7. Email Address (eg, name@fqdn)"
emailAddress_max = 40
myRDN = "8. self-defined RDN"
myRDN_default = "huhu"
myRDN_min = 2
If a CA admin wanted to add different sets of extensions to some of the certificates being issued,
she has to add another extension section to the CAs configuration file. One
could use smime_ext
as an example here: factory fresh it looks like this:
[ smime_ext ]
keyUsage = critical,keyEncipherment,digitalSignature
basicConstraints = CA:false
extendedKeyUsage = emailProtection,msEFS,clientAuth,msSmartcardLogin
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
authorityInfoAccess = @issuer_info
crlDistributionPoints = @crl_info
#certificatePolicies = smimeCPS
CustomOid1 = ASN1:UTF8String:My custom extension's value
#The ia5org option changes the type of the organization field. In RFC2459 it can only be of type DisplayText. In RFC3280 IA5String is also permissible
certificatePolicies = ia5org, cabforum-extended-validation, @polsect
One could add a new section named smimeContentCommitment_ext
like the one
shown below:
[ smimeContentCommitment_ext ]
keyUsage = critical,nonRepudiation,keyEncipherment,digitalSignature
basicConstraints = CA:false
extendedKeyUsage = emailProtection,msEFS,clientAuth,msSmartcardLogin
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
authorityInfoAccess = @issuer_info
crlDistributionPoints = @crl_info
#certificatePolicies = smimeCPS
CustomOid1 = ASN1:UTF8String:My custom extension's value
#The ia5org option changes the type of the organization field. In RFC2459 it can only be of type DisplayText. In RFC3280 IA5String is also permissible
certificatePolicies = ia5org, cabforum-extended-validation, @polsect
If one wanted to issue pre certificates in the context of Certificate Transparency, one had to add the Poison Extension
1.3.6.1.4.1.11129.2.4.3 = critical,ASN1:NULL:
to the corresponding extension section.
There are a lot more intricate extension values possible by constructing them directly as ASN1-Structures as this example shows - the extension is defined as ASN1 sequence and this sequence is then defined by two more sections (the complete documentation about definige arbitrary ASN1 structures can be found here):
SMIME-CAPS = ASN1:SEQUENCE:smime_seq
[ smime_seq ]
SMIMECapability.0 = SEQWRAP,OID:sha1
SMIMECapability.1 = SEQWRAP,OID:sha256
SMIMECapability.2 = SEQWRAP,OID:sha1WithRSA
SMIMECapability.3 = SEQWRAP,OID:aes-256-ecb
SMIMECapability.4 = SEQWRAP,OID:aes-256-cbc
SMIMECapability.5 = SEQWRAP,OID:aes-256-ofb
SMIMECapability.6 = SEQWRAP,OID:aes-128-ecb
SMIMECapability.7 = SEQWRAP,OID:aes-128-cbc
SMIMECapability.8 = SEQWRAP,OID:aes-128-ecb
SMIMECapability.9 = SEQUENCE:rsa_enc
[ rsa_enc ]
capabilityID = OID:rsaEncryption
parameter = NULL
Another example can be found here: It adds another custom ASN1 structure as extension:
1.2.3.4.5.6.7.8.9 = ASN1:SEQUENCE:CustomExt
[CustomExt]
wrappingSeq = SEQUENCE:ExtOid
key = FORMAT:HEX,BITSTRING:abcdef1234556789
[ExtOid]
oid = OID:1.3.101.110
Further information about using specific ASN1 datatypes when adding custom Extensions:
1.2.3.4.5.6.7.1 = ASN1:UTF8String:UTF8STRING
1.2.3.4.5.6.7.2 = ASN1:PRINTABLESTRING:"PRINTABLESTRING"
1.2.3.4.5.6.7.3 = ASN1:IA5STRING:"IA5STRING"
1.2.3.4.5.6.7.4 = ASN1:VISIBLESTRING:"VISIBLESTRING"
1.2.3.4.5.6.7.5 = ASN1:UTCTIME:"9604152030Z"
1.2.3.4.5.6.7.6 = ASN1:UTCTIME:"2210101418+0400"
1.2.3.4.5.6.7.7 = ASN1:INTEGER:0x04112233445566778899aabbccddeeff
1.2.3.4.5.6.7.8 = ASN1:BITSTR:0x04112233445566778899aabbccddeeff #this is probably not what you want!
1.2.3.4.5.6.7.9 = ASN1:GENERALIZEDTIME:"202210101418+0400"
1.2.3.4.5.6.7.10 = ASN1:FORMAT:HEX,BITSTR:04112233445566778899aabbccddeeff
Policies can (and should be) added to certificates. While the CA is free to define new ones it is poossible to use pre-defined ones - for example the ones found below OID arc 2.23.140.1 as detailed here.