SAP Cloud Integration (aka CPI) allows to send messages from an iFlow to an Event Broker via AMQP.
The AMQP adapter can be configured with Basic Authentication or with Client Certificate.
This blog post shows how to configure client certificate authentication in iFlow for sending messages to Solace PubSub+ Event Broker.
Overview
Part 1: Intro
Part 2 : Create Certificate Chain (this blog post)
2.0. Preparation
2.1. Root CA
2.2. Intermediate CA
2.3. Client Certificate
2.4. Container file
Appendix 1: OpenSSL: Installation
Appendix 2: Adding Secure Options
Appendix 3: OpenSSL: Chain of 1
Appendix 4: OpenSSL: Chain of 2
Appendix 5: Java Keytool: Create Certificate Chain
Appendix 6: Using SAP Chain
Appendix 7: OpenSSL Config File
Part 3: Configure Solace
Part 4: Configure CPI, create iFlow, run
Part 2: Create Client Certificate Chain
We need a key pair and a certificate chain that can be validated by Solace server.
What is it?
See Intro blog post. and also checkout the Security Glossary article.
How to get it?
There are multiple possibilities:
🔷The length of the chain:
- length can be just 1: we can use a self-signed certificate and upload it at Solace.
- length can be 2: the root CA and the client.
root is uploaded at solace and client is sent by CPI.
- nice length of 3: root, intermediate and client.
We choose this for our detailed tutorial.
🔷The tool used to create the chain
- we show the usage of OpenSSL, probably the most widely used tool
- in the Appendix 5, we show the usage of the Java Keytool, available on every Java environment.
- there must be user-friendly tools to achieve the same, but they don’t require a tutorial, I guess.
🔷Finally, we can use an existing chain:
- CPI is delivered with a default certificate chain.
You can use it, if you don’t want to create own chain.
However, this should be used only for testing purpose.
It is explained in Appendix 6.
So let’s start creating our own chain using OpenSSL.
See Appendix 1 for help on installation.
2.0. Preparation
We create an empty folder of our choice. E.g. c:\solace
We create a text file called extensions.cfg with the following content:
basicConstraints=CA:TRUE
This is an absolute minimal content for v3-extensions (see Appendix 2 for more content).
This extensions.cfg file will be added to our root CA and intermediate CA certificates.
It identifies them as CA.
2.1. Root CA
In this section we take over the role of a “Certification Authority”.
We create private key and certificate for the root CA certificate.
Generate private key for the root CA
openssl genpkey -algorithm RSA -out root.privkey
The genpkey command is used for generating private keys and allows more options to increase security (See Appendix 2).
Create certificate signing request (CSR) for the root
openssl req -new -key root.privkey -out root.csr -subj "/CN=demoroot"
The req command is used to create certificate signing requests (PKCS10 format).
It requires a private key and outputs the CSR file in PEM format.
Usually, it is configured with a config file.
However, we specify the "subject" as a parameter to make life easier.
Note that we only specify the “Common Name” (CN), to make it short for testing.
See Appendix 2 for full "subject".
Create certificate
openssl x509 -req -in root.csr -extfile extensions.cfg -signkey root.privkey -out root.cert
The x509 command is used for many certificate-related operations.
We pass the signing request file (.csr) and receive the certificate file (.cert).
The private key has to be passed, for signing.
In this case, the certificate is self-signed.
That's normal for root CAs.
We also specify the extensions file, to add the v3-extension (CA:TRUE).
Note
Generating a CSR and signing it can be done in one command.
The reason why we don’t do it: v3-extensions that might be existing in the CSR (due to config file) are not considered when creating the certificate (see openssl docu).
That’s why we have to provide parameters for the x509 command, to get the v3-extensions into the final certificate.
That’s why we use the -extfile option, which is only available for the x509 command.
The newer version 3 of OpenSSL makes life easier.
Alternatively, using a config file for each req command would be possible (but more effort).
View the content of certificate
openssl x509 -noout -text -in root.cert
Above x509 command prints the content of the specified file.
We can see e.g. the “Common Name” (CN) that we’ve specified above.
"Subject" and "Issuer" are same: means, this is the root CA.
We can see the basic constraint which we provided with the extension file and which states that this certificate represents a CA.
2.2. Intermediate CA
In this section we’re still in the role of a “Certification Authority”.
We create key and certificate for the intermediate CA.
This intermediate CA will be responsible for issuing client certificates.
Reason:
Client certificates should expire quickly and thus frequent CSR are sent to the CA.
To handle so many requests, the root creates helper sub-CAs.
Create private key
openssl genpkey -algorithm RSA -out middle.privkey
Create CSR
openssl req -new -key middle.privkey -out middle.csr -subj "/CN=demomiddle"
Create certificate
openssl x509 -req -in middle.csr -CA root.cert -CAkey root.privkey -extfile extensions.cfg -out middle.cert -CAcreateserial
The signing request of intermediate cert is processed with the key and cert of the root CA.
We add the same extensions file, to add CA:TRUE to the intermediate certificate.
Note:
Usually, there would be separate config and extension files for each certificate request.
View intermediate certificate
openssl x509 -noout -text -in middle.cert
We view the (decoded) content of the certificate and make sure that the v3-extensions are contained.
At this point we have a valid intermediate certificate which is signed by the root CA.
It has v3 extension CA:TRUE which is required to make the chain valid.
We can already use it to sign client CSRs.
But let's use the verify command.
Verify intermediate certificate
openssl verify -CAfile root.cert middle.cert
The verify command is used to verify a certificate against the issuer.
Result should be OK
Compose chain
Now we need the chain of our 2 certificates in one PEM file.
Linux users (or anyone having GIT installed on Windows, opens the GIT bash) just run:
cat middle.cert root.cert > middlechain.cert
This command concatenates our 2 existing certificates into one new chain-file.
The root certificate is on bottom.
Same can be achieved manually:
🔸Create new empty text file with name middlechain.cert
(the content is text, the extension has no meaning. We use it to better visualize what is inside).
🔸Copy the content of middle.cert file and paste it into the new file.
🔸Then copy the content of root.cert and paste it into the same new file, below the intermediate.
There should be no blank line in between.
Refer to the screenshot of the chain above.
Verify middle.cert against chain
openssl verify -CAfile middlechain.cert middle.cert
We repeat the command, but this time we use the chain to verify the intermediate certificate.
2.3. Client
In this section we take over the role of a client, which can be a user or a software component (e.g. an iFlow).
We create key and CSR.
Afterwards we switch the role: we’re CA and sign the CSR.
Private Key
openssl genpkey -algorithm RSA -out client.privkey
CSR
openssl req -new -key client.privkey -out client.csr -subj "/CN=democlient"
Create certificate
openssl x509 -req -in client.csr -CA middle.cert -CAkey middle.privkey -CAcreateserial -out client.cert
We don’t need an extension for the client.
However, it could make sense to add a basic constraint as CA:FALSE
This would ensure that nobody could use our client cert for signing new certificates.
View client certificate
openssl x509 -noout -text -in client.cert
Verify client cert
openssl verify -CAfile root.cert -untrusted middle.cert client.cert
compose chain
Now we need the full chain with all 3 certificates:
cat client.cert middle.cert root.cert > clientchain.cert
It can be created manually same way as described above:
Create new file
🔸Paste client cert
🔸Paste middle cert below
🔸Paste root cert at bottom
Verify client.cert against chain
openssl verify -CAfile clientchain.cert -untrusted middle.cert client.cert
To make sure that the chain is built properly, we’ve used the verify command.
To view the decoded content, we cannot use the x509 command, as it prints only one cert.
We will view the content later, using the pkcs12 command
We’re done with our certificate chain.
2.4. Container (.p12) file
One last step is required, for the admin role of the client.
To upload the private key and chain, we need a container format like .p12 (aka pfx, specified in PKCS12).
It is used to securely store private keys and certificates in binary format and protected with password.
Thus, it is perfect for transmitting such security artifacts over the net.
openssl pkcs12 -export -out demostore.p12 -inkey client.privkey -in clientchain.cert -name democlient -passout pass:abcd
The pkcs12 command is used to deal with p12 files.
To create new file, the param -export is used.
The input for the new file are the private key and the client chain.
The -name parameter allows to specify an alias.
This is relevant for us, because the alias with be shown in the CPI keystore.
For the sake of simplicity, we specify the password on command line.
Please refer to the OpenSSL docu to learn how to pass the password invisibly (e.g. interactively on command line, or in a file).
Note:
We store only the client certificate in the p12.
This is enough, because we have the chain.
Note:
For the sake of interest or performance:
The contained chain can be shorter: it does not necessarily need the root cert.
We can remove the root cert, which is at the bottom of the chain.
Reason is that solace has the root available at the “Client Certificate Authorities”.
As such, Solace is able to verify the chain, even if we don’t send the whole chain.
However, the intermediate (or all intermediates, if there are multiple) must be sent with the client cert.
Note that this practice might not be supported by all servers.
View content of p12 file
openssl pkcs12 -in demostore.p12 -info -nodes -passin pass:abcd
Above command prints the certificate chain and private key.
The password can be omitted, then it has to be provided interactively.
We use -nodes to view the private key unencrypted.
To print the contained encoded certificate and private key, we use -info which prints bag attributes as well.
Summary
🔹Above section looks long, but basically, we’ve just created 3 keys and certificates.
🔹In addition, we’ve composed 2 chains.
🔹And we’ve put the result into a p12 file.
The next 2 blog posts of the series will be using these artifacts.
And they will be much shorter 😉
Next Steps
🔹Part 3: Configure Solace PubSub+ Event Broker
🔹Part 4: Configure CPI, create iFlow, run scenario
Links
OpenSSL
genpkey
req
X509
verify
pkcs12
How to secretly passing a password to commands
Appendix 1: OpenSSL: Installation
OpenSSL is the most commonly used tool (and library) for security-related operations, dealing with certificates, keys, converting, etc etc
Basically, it consists of libraries (for “c”) and a command line tool.
If you have GIT installed, you can just open the git bash which contains openssl.
Otherwise, follow these instructions to install OpenSSL under Windows:
Download OpenSSL starting from here.
Afterwards it might be required to add the openssl.exe to the PATH.
If you get this error:
Unable to load config info from /usr/local/ssl/openssl.cnf
You need to set an environment variable.
e.g. on command line:
set OPENSSL_CONF=c:/tools/openssl/openssl.cfg
Note:
For windows, the config-file extension .cnf has to be adjusted to .cfg
A template .cnf file can be found in GIT installation folder.
Appendix 2: Adding Secure Options
Bigger key size:
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out root.privkey
Encrypted private key with password:
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out cpiclient.privkey -aes-256-cbc -pass pass:abcd
Add validity days:
openssl req -new -x509 -days 365 -key root.privkey -out root.cert -subj "/CN=rootca"
Note:
CA should have long duration (e.g. 5 years)
Client should have short duration
Add digest algo:
openssl req -new -x509 -sha512 -key root.privkey -out root.cert -subj "/CN=rootca"
Note:
In this example, SHA512 algorithm is used to sign the certificate request(alternatively -sha256).
Add full Subject DN:
-subj '/CN=My Root CA/C=DE/ST=Walldorf/L=Walldorf/O=MyOrganisation’
Additional content in extensions.cfg
keyUsage=critical, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
authorityKeyIdentifier = keyid,issuer:always
basicConstraints=critical,CA:FALSE
extendedKeyUsage=critical,serverAuth
subjectKeyIdentifier = hash
nsCertType = server
nsComment = "any comment here"
Appendix 3: OpenSSL: Chain of 1
Example for chain of 1: create self-signed certificate
This is a root certificate, so it can be uploaded to Solace.
It can be used as client certificate as well, so it is uploaded to CPI, too.
openssl req -x509 -newkey rsa -nodes -keyout demoself.privkey -out demoself.cert -subj "/CN=demoself"
openssl pkcs12 -export -out demoselfstore.p12 -inkey demoself.privkey -in demoself.cert -name demoself -passout pass:abcd
Solace:
Upload demoself.cert
Create username as “demoself”
CPI:
upload demoselfstore.p12 to keystore
use “demoself” as private key alias in iFlow
Appendix 4: OpenSSL: Chain of 2
Example for a chain with 2 certificates: root and client
openssl req -newkey rsa -nodes -keyout roottwo.privkey -x509 -out roottwo.cert -subj "/CN=roottwo"
openssl genpkey -algorithm RSA -out clienttwo.privkey
openssl req -new -key clienttwo.privkey -out clienttwo.csr -subj "/CN=democlienttwo"
openssl x509 -req -in clienttwo.csr -CA roottwo.cert -CAkey roottwo.privkey -CAcreateserial -out clienttwo.cert
openssl pkcs12 -export -out clienttwostore.p12 -inkey clienttwo.privkey -in clienttwo.cert -name democlienttwo -passout pass:abcd
Appendix 5: Java Keytool: Create Certificate Chain
Example for a chain with 3 certificates, created with Java keytool.
We’re using separate keystores for each entity
The v3-extensions are passed as parameter
Root CA
Create key pair and certificate
keytool -genkeypair -keystore root.jks -alias rootca -ext bc:c -dname "CN=demorootca" -storepass abcd1234
Export the generated certificate to file system
keytool -exportcert -keystore root.jks -alias rootca -rfc -file root.cert -storepass abcd1234
Note:
-rfc indicates PEM format
Intermediate CA
Create key pair and certificate
keytool -genkeypair -keystore middle.jks -alias middleca -ext bc:c -dname "CN=demomiddleca" -storepass abcd1234
Create certificate signing request (CSR)
keytool -certreq -keystore middle.jks -alias middleca -file middle.csr -storepass abcd1234
Create middle cert which is signed by root
keytool -gencert -keystore root.jks -alias rootca -ext BC=0 -rfc -infile middle.csr -outfile middle.cert -storepass abcd1234
Compose chain file where the root is bottom (“root rear”)
cat middle.cert root.cert > middlechain.cert
Install middle cert chain in keystore
keytool -importcert -keystore middle.jks -alias middleca -file middlechain.cert -storepass abcd1234
Client
Create key pair and certificate
keytool -genkeypair -keystore client.jks -alias democlient -dname "CN=democlient" -storepass abcd1234
Create CSR for client
keytool -certreq -keystore client.jks -alias democlient -file client.csr -storepass abcd1234
Create client cert which is signed by middle
keytool -gencert -keystore middle.jks -alias middleca -rfc -infile client.csr -outfile client.cert -storepass abcd1234
Note:
V3 extensions can be added, optional
-ext ku:c=dig,keyEncipherment
Compose chain file where the root is bottom (“root rear”)
cat client.cert middle.cert root.cert > clientchain.cert
Note:
Reverse order with root on top and client at bottom may work fine as well, it depends on server
Install client cert chain in keystore
keytool -importcert -keystore client.jks -alias democlient -file clientchain.cert -storepass abcd1234
Optional
Verify chain
openssl verify -CAfile root.cert -untrusted middle.cert client.cert
View cert
openssl x509 -in client.cert -text -noout
CPI
Upload client.jks to CPI Keystore
Appendix 6: Using SAP Chain
In this example, it is not required at all to create any own certificate.
Instead, we use the certificate chain which is delivered with SAP Cloud Integration
1. Download certificate
We go to the CPI Keystore at <tenant>/shell/monitoring/Keystore
We find the (unmodifiable) sap_cloudintegrationcertificate
From the context button, we choose “Download Root Certificate”
We go to Solace console and upload the downloaded sap_cloudintegrationcertificate_rootCA.cer
3. Create Username in Solace
In the Solace Broker Manager we have to create a new username with the CN of the sap_cloudintegrationcertificate.
To find the CN, we go to the CPI Keystore, find the entry for sap_cloudintegrationcertificate.
Either from the table, or from the Details page, we find the “Subject DN” and from there, we copy the value of the CN.
In my example: “sap-cpi-test-only-not-for-prod.hana.ondemand.com”
This value is used for creating a username in Solace.
4. Configure AMQP adapter
We go to CPI keystore and copy the alias name to clipboard: "sap_cloudintegrationcertificate".
We go to our iFlow and paste this alias name into the “Private Key Alias” field of the AMQP adapter.
Note:
If you encounter a .p7b file after download artifacts, you can extract it with the help of OpenSSL and the pkcs7 command:
openssl pkcs7 -in demokeypair.p7b -print_certs -out certificate.cerAppendix 7: OpenSSL Config File
Below sample is copied from GIT installation folder
openssl.cnf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# Note that you can include other files from the main configuration
# file using the .include directive.
#.include filename
# This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several certs with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
x509_extensions = usr_cert # The extensions to add to the cert
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = default # use public key default MD
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extensions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Some-State
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Internet Widgits Pty Ltd
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
####################################################################
[ tsa ]
default_tsa = tsa_config1 # the default TSA section
[ tsa_config1 ]
# These are used by the TSA reply generation only.
dir = ./demoCA # TSA root directory
serial = $dir/tsaserial # The current serial number (mandatory)
crypto_device = builtin # OpenSSL engine to use for signing
signer_cert = $dir/tsacert.pem # The TSA signing certificate
# (optional)
certs = $dir/cacert.pem # Certificate chain to include in reply
# (optional)
signer_key = $dir/private/tsakey.pem # The TSA private key (optional)
signer_digest = sha256 # Signing digest to use. (Optional)
default_policy = tsa_policy1 # Policy if request did not specify it
# (optional)
other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional)
digests = sha1, sha256, sha384, sha512 # Acceptable message digests (mandatory)
accuracy = secs:1, millisecs:500, microsecs:100 # (optional)
clock_precision_digits = 0 # number of digits after dot. (optional)
ordering = yes # Is ordering defined for timestamps?
# (optional, default: no)
tsa_name = yes # Must the TSA name be included in the reply?
# (optional, default: no)
ess_cert_id_chain = no # Must the ESS cert id chain be included?
# (optional, default: no)
ess_cert_id_alg = sha1 # algorithm to compute certificate
# identifier (optional, default: sha1)
✨✨✨✨✨
- SAP Managed Tags:
