Expect Dialog CA

This repository contains scripts meant to make managing an openssl ca less painful inside a terminal environment

View the Project on GitHub elbosso/expect-dialog-ca

How can i customize my CA?

Before creation

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.

During creation

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:

type of CA

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:

name of CA

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!

OCSP responder for CA

Now, the script shows the information read from ca_presets.ini (if applicable):

options read from ca_presets.ini

And the user can afterwards change / enter the Distinguishes Name for the CA:

DN for 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):

key length

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):

key length

and the hash or message digest algorithm:

message digest

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.

CSR defaults info

It is not necessary to specify such defaults for all flavours - you can choose which ones you want:

flavours for CSR defaults

If you choose at least one - a dialog like this one here is displayed to enter the default values:

CSR defaults dialog

Afterwards, you are informed that you can specify Certificate Policy Statements (CPSs) for each flavour:

CSP info

It is not necessary to specify CPSs for all flavours - you can choose which ones you want:

flavours for CPSs

If you choose at least one - a dialog like this one here is displayed to let you enter the information for each CPS:

CPS info dialog

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:

custom OID info

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:

custom OID dialog

Now, you have to enter a password to protect the private key of the CA:

private key password dialog

The next step is to specify the location for the log:

log location

Then, the certificate signing request is displayed:

CSR for CA

And that concludes the process - the script shows some informational messages to wrap it all up:

info display

info policy display

info publish display

info log display

After creation

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:

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:

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.