REM *******************************************************************************
REM The MIT License (MIT)
REM
REM Copyright (c) 2015-2017 V2G Clarity (Dr. Marc Mültin)
REM
REM Copyright (c) 2015-2018 V2G Clarity (Dr. Marc Mültin)
REM
REM Permission is hereby granted, free of charge, to any person obtaining a copy
REM of this software and associated documentation files (the "Software"), to deal
@ -23,19 +23,22 @@ REM OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
REM THE SOFTWARE.
REM *******************************************************************************
REM ===========================================================================================================
REM This shell script can be used to create all necessary certificates and keystores needed in order to
REM ===============================================================================================================
REM This shell script can be used to create all necessary certificates and Keystores needed in order to
REM - successfully perform a TLS handshake between the EVCC (TLSClient) and the SECC (TLSServer) and
REM - install/update a contract certificate in the EVCC.
REM
REM This file shall serve you with all information needed to create your own certificate chains.
REM
REM
REM Helpful information about using openssl is provided by Ivan Ristic's book "Bulletproof SSL and TLS".
REM Furthermore, you should have openssl 1.0.2 (or above) installed to comply with all security requirements
REM imposed by ISO 15118. For example, openssl 0.9.8 does not come with SHA-2 for SHA-256 signature algorithms.
REM
REM Some MacOS X installations unfortunately still use openssl < v1.0.2. You could use Homebrew to install openssl.
REM Be aware that you probably then need to use an absolute path for your openssl commands, such as
REM /usr/local/Cellar/openssl/1.0.2h_1/bin/openssl.
REM
REM Author: Dr. Marc Mültin (marc.mueltin@v2g-clarity.com)
REM ===========================================================================================================
REM ===============================================================================================================
REM Some variables to create different outcomes of the PKI for testing purposes. Change the validity periods (given in number of days) to test
@ -58,170 +61,212 @@ SET validity_v2g_root_cert=3650
SETvalidity_oem_root_cert=3650
SETvalidity_mo_root_cert=3650
REM FURTHER REMARKS:
REM 1. OpenSSL does not use the named curve 'secp256r1' but the equivalent 'prime256v1'. So this file uses only 'prime256v1'.
REM 2. The password used is stored in the file passphrase.txt. In it, you'll find two lines. The first line is used for the -passin option, the second line for the -passout option (especially when dealing with PKCS12 containers). See also https://www.openssl.org/docs/man1.0.2/apps/openssl.html, section "Pass Phrase Arguments"
REM 0) Create directories if not yet existing. The keystores in the keystores folder (if existing) need to be deleted at first, so delete the complete folder.
ifexist keystores rd /s /q keystores
REM 0) Create directories if not yet existing
ifexist keystores rd /s /q keystores REM the keystores in the keystores folder (if existing) need to be deleted at first, so delete the complete folder
ifnotexist certs mkdir certs
ifnotexist csrs mkdir csrs
ifnotexist keystores mkdir keystores
ifnotexist privateKeys mkdir privateKeys
REM 1) Create a self-signed V2GRootCA certificate
REM 1.1) Create a
REM 1.1) Create a private key
REM - private key -> -genkey
REM - with elliptic curve parameters -> ecparam
REM - for key of length 256 bit to be used for digital signatures -> -name secp256r1
REM - with symmetric encryption AES 128 bit -> -aes128
REM - and the passphrase for the private key provided in a file -> -passout file:passphrase.txt
REM 2.3) Create an X.509 certificate (same procedure as for V2GRootCA, but with the difference that we need the ‘-CA’ switch to point to the CA certificate, followed by the ‘-CAkey’ switch that tells OpenSSL where to find the CA’s private key. We need the private key to create the signature and the public key certificate to make sure that the CA’s certificate and private key match.
REM 3) Create a second intermediate CPO sub-CA certificate just the way the previous intermedia certificate was created which is directly signed by the CPOSubCA1
REM 3) Create a second intermediate CPO sub-CA certificate (sub-CA 2) just the way the previous intermedia certificate was created which is directly signed by the CPOSubCA1
REM Differences to CPOSubCA1
REM - basicConstraints in config file sets pathlength to 0 (meaning that no further sub CA's certificate may be signed with this certificate, a leaf certificate must follow this certificate in a certificate chain)
REM - validity is set to 1 year (1 - 2 years are allowed according to ISO 15118)
REM - basicConstraints in config file sets pathlength to 0 (meaning that no further sub-CA certificates may be signed with this certificate, a leaf certificate must follow this certificate in a certificate chain)
REM - validity is set to 1 year (1 - 2 years are allowed according to ISO 15118)
REM 4) Create an SECCCert certificate which is the leaf certificate belonging to the charging station which authenticates itself to the EVCC during a TLS handshake, signed by CPOSubCA2 certificate
REM Differences to CPOSubCA1 and CPOSubCA2
REM - basicConstraints sets CA to false, no pathlen is therefore set
REM - keyusage is set to digitalSignature instead of keyCertSign and cRLSign
REM - validity is set to 60 days (2 - 3 months are allowed according to ISO 15118)
REM Concatenate the intermediate CAs into one file intermediateCAs.pem
REM IMPORTANT: Concatenate in such a way that the chain leads from the leaf certificate to the root (excluding), this means here: first parameter of the type command is the intermediate CA's certificate which signs the leaf certificate (in this case cpoSubCA2.pem). Otherwise the Java method getCertificateChain() which is called on the keystore will only return the leaf certificate!
type certs\cpoSubCA2.pem certs\cpoSubCA1.pem > certs\intermediateCPOCAs.pem
REM Put the seccCertificate, the private key of the seccCertificate as well as the intermediate CAs in a pkcs12 container.
REM IMPORTANT: It is necessary to put all necessary intermediate CAs directly into the PKCS12 container (with the -certfile switch), instead of later on iporting the PKCS12 containter only holding the leaf certificate (seccCert) and its private key and additionally importing the intermediate CAs via the keytool command (TLS handshake will fail).
REM This is the reason why we need two password files (passphrase.txt and passphrase2.txt). Possibly the passphrase.txt file resource is locked before being accessed a second time within the same command? See also http://rt.openssl.org/Ticket/Display.html?id=3168&user=guest&pass=guest
REM The -name switch corresponds to the -alias switch in the keytool command later on
REM 6) Create an intermediate OEM sub-CA certificate which is directly signed by the OEMRootCA certificate (validity is up to the OEM, this example applies the same validity as the CPOSubCA1)
REM 7) Create a second intermediate OEM sub-CA certificate which is directly signed by the OEMSubCA1 certificate (validity is up to the OEM, this example applies the same validity as the CPOSubCA2)
REM 8) Create an OEM provisioning certificate which is the leaf certificate belonging to the OEM certificate chain (used for contract certificate installation)
REM 9) Create a self-signed MORootCA (mobility operator) certificate (validity is up to the MO, this example applies the same validity as the V2GRootCA)
REM 10) Create an intermediate MO sub-CA certificate which is directly signed by the MORootCA certificate (validity is up to the MO, this example applies the same validity as the CPOSubCA1)
REM 11) Create a second intermediate MO sub-CA certificate which is directly signed by the MOSubCA1 certificate (validity is up to the MO, this example applies the same validity as the CPOSubCA2)
REM 14) Create a second intermediate provisioning sub-CA certificate which is directly signed by the CPSSubCA1 certificate (validity 1 - 2 years, we make it 2 years)
REM 15) Create a provisioning service certificate which is the leaf certificate belonging to the provisioning certificate chain (used for contract certificate installation)
REM Validity can be between 2 - 3 months, we make it 3 months
REM 16) Finally we need to convert the certificates from PEM format to DER format (PEM is the default format, but ISO 15118 only allows DER format)
openssl x509 -inform PEM -in certs\v2gRootCA.pem -outform DER -out certs\v2gRootCA.der
openssl x509 -inform PEM -in certs\cpsSubCA1.pem -outform DER -out certs\cpsSubCA1.der
openssl x509 -inform PEM -in certs\cpsSubCA2.pem -outform DER -out certs\cpsSubCA2.der
openssl x509 -inform PEM -in certs\cpsLeafCert.pem -outform DER -out certs\cpsLeafCert.der
openssl x509 -inform PEM -in certs\cpoSubCA1.pem -outform DER -out certs\cpoSubCA1.der
openssl x509 -inform PEM -in certs\cpoSubCA2.pem -outform DER -out certs\cpoSubCA2.der
openssl x509 -inform PEM -in certs\v2gRootCACert.pem -outform DER -out certs\v2gRootCACert.der
openssl x509 -inform PEM -in certs\cpsSubCA1Cert.pem -outform DER -out certs\cpsSubCA1Cert.der
openssl x509 -inform PEM -in certs\cpsSubCA2Cert.pem -outform DER -out certs\cpsSubCA2Cert.der
openssl x509 -inform PEM -in certs\cpsLeafCert.pem -outform DER -out certs\cpsLeafCert.der
openssl x509 -inform PEM -in certs\cpoSubCA1Cert.pem -outform DER -out certs\cpoSubCA1Cert.der
openssl x509 -inform PEM -in certs\cpoSubCA2Cert.pem -outform DER -out certs\cpoSubCA2Cert.der
openssl x509 -inform PEM -in certs\seccCert.pem -outform DER -out certs\seccCert.der
openssl x509 -inform PEM -in certs\oemRootCA.pem -outform DER -out certs\oemRootCA.der
openssl x509 -inform PEM -in certs\oemSubCA1.pem -outform DER -out certs\oemSubCA1.der
openssl x509 -inform PEM -in certs\oemSubCA2.pem -outform DER -out certs\oemSubCA2.der
openssl x509 -inform PEM -in certs\oemRootCACert.pem -outform DER -out certs\oemRootCACert.der
openssl x509 -inform PEM -in certs\oemSubCA1Cert.pem -outform DER -out certs\oemSubCA1Cert.der
openssl x509 -inform PEM -in certs\oemSubCA2Cert.pem -outform DER -out certs\oemSubCA2Cert.der
openssl x509 -inform PEM -in certs\oemProvCert.pem -outform DER -out certs\oemProvCert.der
openssl x509 -inform PEM -in certs\moRootCA.pem -outform DER -out certs\moRootCA.der
openssl x509 -inform PEM -in certs\moSubCA1.pem -outform DER -out certs\moSubCA1.der
openssl x509 -inform PEM -in certs\moSubCA2.pem -outform DER -out certs\moSubCA2.der
openssl x509 -inform PEM -in certs\moRootCACert.pem -outform DER -out certs\moRootCACert.der
openssl x509 -inform PEM -in certs\moSubCA1Cert.pem -outform DER -out certs\moSubCA1Cert.der
openssl x509 -inform PEM -in certs\moSubCA2Cert.pem -outform DER -out certs\moSubCA2Cert.der
openssl x509 -inform PEM -in certs\contractCert.pem -outform DER -out certs\contractCert.der
REM Since the intermediate certificates need to be in PEM format when putting them in a PKCS12 container and the resulting PKCS12 file is a binary format, it might be sufficient. Otherwise, I have currently no idea how to covert the intermediate certificates in DER without running into problems when creating the PKCS12 container.
REM 17) In case you want the private keys in PKCS#8 file format and DER encoded, use this command. Especially necessary for the private key of MOSubCA2 in RISE V2G
REM 17) In case you want the private keys in PKCSREM8 file format and DER encoded, use this command. Especially necessary for the private key of MOSubCA2 in RISE V2G
REM XX) Create the initial Java truststores and keystores
REM XX.1) truststore for the EVCC which needs to hold the V2GRootCA certificate (the EVCC does not verify the received contract certificate chain, therefore no MORootCA needs to be imported in evccTruststore.jks )
REM XX.2) truststore for the SECC which needs to hold the V2GRootCA certificate and the MORootCA which signed the MOSubCA1 (needed for verifying the contract certificate signature chain which will be sent from the EVCC to the SECC with PaymentDetailsReq message). According to ISO 15118-2, MORootCA is not necessarily needed as the MOSubCA1 could instead be signed by a V2GRootCA.
REM 18) Create the keystores for the EVCC and SECC. We need to first create the PKCS12 files and then import them into the JKS using the 'keytool' command.
REM - create a PKCS12 file -> -export
REM - if no private keys are added, e.g. for a truststore that holds only root CA certificates -> -nokeys
REM - add a private key to the newly created PKCS12 container; must be in PEM format (not DER) -> -inkey
REM - add any certificate (leaf certificate or root certificate); must be in PEM format (not DER) -> -in
REM - add additional certificats (intermediate sub-CA certificates or more root CA certificates); must be in PEM format (not DER) -> -certfile
REM - use AES to encrypt private keys before outputting -> -aes128
REM - passphrase source to decrypt any private keys that are to be imported -> -passin
REM - passphrase to encrypt any outputted private keys with -> -passout
REM - provide the "friendly name" for the leaf certificate, which is used as the alias in Java -> -name
REM - provide the "friendly name" for CA certificates, which is used as the alias in Java;
REM this option may be used multiple times to specify names for all certificates in the order they appear -> -caname
REM - the file location to store the PKCS12 data container -> -out
REM
REM 18.1) SECC keystore needs to hold initially hold the OEM provisioning certificate (contract certificate will be installed with ISO 15118 message exchange)
REM First, concatenate the intermediate sub-CA certificates into one file intermediateCAs.pem
REM IMPORTANT: Concatenate in such a way that the chain leads from the leaf certificate to the root (excluding), this means here: first parameter of the type command is the sub-CA certificate which signs the leaf certificate (in this case cpoSubCA2.pem). Otherwise the Java method getCertificateChain() which is called on the keystore will only return the leaf certificate!
type certs\cpoSubCA2Cert.pem certs\cpoSubCA1Cert.pem > certs\intermediateCPOCACerts.pem
REM Put the seccCertificate, the private key associated with the seccCertificate as well as the intermediate sub-CA certificates in a PKCS12 container with the -certfile switch.
REM 18.2) EVCC keystore needs to initally hold the OEM provisioning certificate (contract certificate will be installed with ISO 15118 message exchange)
type certs\oemSubCA2Cert.pem certs\oemSubCA1Cert.pem > certs\intermediateOEMCACerts.pem
REM Side notes for OCSP stapling in Java: see http://openjdk.java.net/jeps/8046321
REM 19) Create truststores for EVCC and SECC. Storing trust anchors in PKCS12 is not supported in Java 8. For creating trusstores we need a Java KeyStore (JKS) and import the DER encoded root CA certificates.
REM
REM 19.1) EVCC truststore needs to hold the V2GRootCA certificate
# OpenSSL does not use the named curve 'secp256r1' but the equivalent 'prime256v1'. So this file uses only 'prime256v1'.
# FURTHER REMARKS:
# 1. OpenSSL does not use the named curve 'secp256r1' but the equivalent 'prime256v1'. So this file uses only 'prime256v1'.
# 2. The password used is stored in the file passphrase.txt. In it, you'll find two lines. The first line is used for the -passin option, the second line for the -passout option (especially when dealing with PKCS12 containers). See also https://www.openssl.org/docs/man1.0.2/apps/openssl.html, section "Pass Phrase Arguments"
# 0) Create directories if not yet existing
@ -79,7 +81,7 @@ mkdir -p privateKeys
# - encrypt the key with symmetric cipher AES-128-CBC using the 'ec' utility command -> ec -aes-128-cbc
# - the passphrase for the encryption of the private key is provided in a file -> -passout file:passphrase.txt
# - save the encrypted private key at the location provided -> -out
# Concatenate the intermediate CAs into one file intermediateCAs.pem
# IMPORTANT: Concatenate in such a way that the chain leads from the leaf certificate to the root (excluding), this means here: first parameter of the cat command is the intermediate CA's certificate which signs the leaf certificate (in this case cpoSubCA2.pem). Otherwise the Java method getCertificateChain() which is called on the keystore will only return the leaf certificate!
# Put the seccCertificate, the private key of the seccCertificate as well as the intermediate CAs in a pkcs12 container.
# IMPORTANT: It is necessary to put all necessary intermediate CAs directly into the PKCS12 container (with the -certfile switch), instead of later on importing the PKCS12 containter only holding the leaf certificate (seccCert) and its private key and additionally importing the intermediate CAs via the keytool command (TLS handshake will fail).
# This is the reason why we need two password files (passphrase.txt and passphrase2.txt). Possibly the passphrase.txt file resource is locked before being accessed a second time within the same command? See also http://rt.openssl.org/Ticket/Display.html?id=3168&user=guest&pass=guest
# The -name switch corresponds to the -alias switch in the keytool command later on
# 17) In case you want the private keys in PKCS#8 file format and DER encoded, use this command. Especially necessary for the private key of MOSubCA2 in RISE V2G
# XX) Create the initial Java truststores and keystores
# XX.1) truststore for the EVCC which needs to hold the V2GRootCA certificate (the EVCC does not verify the received contract certificate chain, therefore no MORootCA needs to be imported in evccTruststore.jks )
# 18) Create the keystores for the EVCC and SECC. We need to first create the PKCS12 files and then import them into the JKS using the 'keytool' command.
# - create a PKCS12 file -> -export
# - if no private keys are added, e.g. for a truststore that holds only root CA certificates -> -nokeys
# - add a private key to the newly created PKCS12 container; must be in PEM format (not DER) -> -inkey
# - add any certificate (leaf certificate or root certificate); must be in PEM format (not DER) -> -in
# - add additional certificats (intermediate sub-CA certificates or more root CA certificates); must be in PEM format (not DER) -> -certfile
# - use AES to encrypt private keys before outputting -> -aes128
# - passphrase source to decrypt any private keys that are to be imported -> -passin
# - passphrase to encrypt any outputted private keys with -> -passout
# - provide the "friendly name" for the leaf certificate, which is used as the alias in Java -> -name
# - provide the "friendly name" for CA certificates, which is used as the alias in Java;
# this option may be used multiple times to specify names for all certificates in the order they appear -> -caname
# - the file location to store the PKCS12 data container -> -out
#
# 18.1) SECC keystore needs to hold initially hold the OEM provisioning certificate (contract certificate will be installed with ISO 15118 message exchange)
# First, concatenate the intermediate sub-CA certificates into one file intermediateCAs.pem
# IMPORTANT: Concatenate in such a way that the chain leads from the leaf certificate to the root (excluding), this means here: first parameter of the cat command is the sub-CA certificate which signs the leaf certificate (in this case cpoSubCA2.pem). Otherwise the Java method getCertificateChain() which is called on the keystore will only return the leaf certificate!
# Put the seccCertificate, the private key associated with the seccCertificate as well as the intermediate sub-CA certificates in a PKCS12 container with the -certfile switch.
# 19) Create truststores for EVCC and SECC. Storing trust anchors in PKCS12 is not supported in Java 8. For creating trusstores we need a Java KeyStore (JKS) and import the DER encoded root CA certificates.
#
# 19.1) EVCC truststore needs to hold the V2GRootCA certificate
# XX.2) truststore for the SECC which needs to hold the V2GRootCA certificate and the MORootCA which signed the MOSubCA1 (needed for verifying the contract certificate signature chain which will be sent from the EVCC to the SECC with PaymentDetailsReq message). According to ISO 15118-2, MORootCA is not necessarily needed as the MOSubCA1 could instead be signed by a V2GRootCA.
#
# 19.2) SECC truststore needs to hold the V2G root CA certificate and MO root CA certificate.
# According to ISO 15118-2, MO root CA is not necessarily needed as the MO sub-CA 1 could instead be signed by a V2G root CA.
This file provides test data needed to reproduce the same digest and signature values for a CertificateInstallationRes. This test data is provided for your convenience to verify that your implementation of creating and verifying digital XML-based signatures is correct.
Further explanation is given in the ISO 15118 Manual in section 3.11.3 "Test Data To Verify Your CertificateInstallationRes".
For further explanation why the different usage of XML namespace matters with regards to the resulting digest and signature values, have a look at section 3.11.4 "Pitfalls with Signatures And XML Namespaces" in the [ISO 15118 Manual](http://v2g-clarity.com/en/iso15118-masterclass/ebook/).
Further explanation is given in the ISO 15118 Manual in section 3.12.3 "Test Data To Verify Your CertificateInstallationRes".
For further explanation why the different usage of XML namespace matters with regards to the resulting digest and signature values, have a look at section 3.12.4 "Pitfalls with Signatures And XML Namespaces" in the [ISO 15118 Manual](http://v2g-clarity.com/en/iso15118-masterclass/ebook/).
Marc Mültin