Describe the bug

libevse-security no longer builds with the Docker build script in everest-utils, which uses Debian 11 with OpenSSL 1.x.

In commit acc12fe, a dependency to OpenSSL 3 was reintroduced, through the use of (among others) X509_add_cert().

To Reproduce

In everest-utils:

./build.sh --name everest-core-test-01 --conf /path/to/some-config.yaml

Anything else?

See also the recent issues
EVerest/everest-utils#112
and
#31

So I assume OpenSSL 1.x compatibility is still desired.

224.6 [ 31%] Building CXX object _deps/sqlite_cpp-build/CMakeFiles/SQLiteCpp.dir/src/Database.cpp.o
224.7 /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp: In function 'bool evse_security::s_generate_key(const evse_security::KeyGenerationInfo&, evse_security::KeyHandle_ptr&, evse_security::EVP_PKEY_CTX_ptr&)':
224.7 /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp:259:75: warning: 'RSA* RSA_generate_key(int, long unsigned int, void (*)(int, int, void*), void*)' is deprecated [-Wdeprecated-declarations]
224.7   259 |         RSA_ptr rsa_key(RSA_generate_key(bits, RSA_PRIME, nullptr, nullptr));
224.7       |                                                                           ^
224.7 In file included from /usr/include/openssl/e_os2.h:13,
224.7                  from /usr/include/openssl/bio.h:13,
224.7                  from /usr/include/openssl/x509v3.h:13,
224.7                  from /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/include/evse_security/detail/openssl/openssl_types.hpp:6,
224.7                  from /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp:5:
224.7 /usr/include/openssl/rsa.h:235:1: note: declared here
224.7   235 | DEPRECATEDIN_0_9_8(RSA *RSA_generate_key(int bits, unsigned long e, void
224.7       | ^~~~~~~~~~~~~~~~~~
224.7 /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp: In static member function 'static evse_security::CertificateValidationResult evse_security::OpenSSLSupplier::x509_verify_certificate_chain(evse_security::X509Handle*, const std::vector<evse_security::X509Handle*>&, const std::vector<evse_security::X509Handle*>&, bool, std::optional<std::filesystem::__cxx11::path>, std::optional<std::filesystem::__cxx11::path>)':
224.7 /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp:599:21: error: 'X509_ADD_FLAG_NO_DUP' was not declared in this scope; did you mean 'X509_FLAG_NO_AUX'?
224.7   599 |         int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
224.7       |                     ^~~~~~~~~~~~~~~~~~~~
224.7       |                     X509_FLAG_NO_AUX
224.8 /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp:599:44: error: 'X509_ADD_FLAG_NO_SS' was not declared in this scope; did you mean 'X509_FLAG_NO_IDS'?
224.8   599 |         int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
224.8       |                                            ^~~~~~~~~~~~~~~~~~~
224.8       |                                            X509_FLAG_NO_IDS
224.8 /workspace/everest/cpm_source_cache/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp:602:22: error: 'X509_add_cert' was not declared in this scope; did you mean 'X509_add_ext'?
224.8   602 |             if (1 != X509_add_cert(untrusted.get(), get(untrusted_cert), flags)) {
224.8       |                      ^~~~~~~~~~~~~
224.8       |                      X509_add_ext
225.0 make[2]: *** [_deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/build.make:186: _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/crypto/openssl/openssl_supplier.cpp.o] Error 1
225.0 make[1]: *** [CMakeFiles/Makefile2:4449: _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/all] Error 2

Describe the problem

At the moment there is no overview of the TPM usage flow. A doc page should be added related to possible the TPM usage flow.

Describe your solution

No response

Additional context

No response

Describe the bug

When a leaf certificate is expired and it is requested from the module, instead of properly outputting the error with a 'Could not find certificate for given private key' or something long those lines, the error that is outputted is related to a missing private key, which is not the case.

To Reproduce

Attempt to request an expired leaf certificate.

Anything else?

No response

Functions like x509_check_private_key should have an option to use TPM keys

Have an compile-time option to make the library fully thread-safe

Describe the problem

There seem to be different requirements and use cases of how a leaf certificate (SECC or CSMS) shall be selected in case multiple valid certificates are present on the charger.

The current mechanism is to select the certificate with the latest validTo property. However, OCPP requires

The Charge Point SHALL switch to the new certificate as soon as the current date and
time is after the ‘Not valid before’ field in the certificate

This currently causes some OCTT test cases to fail.

Describe your solution

Make the selection mechanism configurable (differntiate between validTo or validFrom to be decisive), to be able to address all use cases.

Additional context

No response

There is the option to protect private keys with a password (passed to the constructor of EvseSecurity).
The result is a PEM file that starts "-----BEGIN ENCRYPTED PRIVATE KEY-----"
When there is no password the following would be expected: "-----BEGIN PRIVATE KEY-----"
(TPM keys start with other strings)

At the moment when there is no password specified an empty password is used and the resulting file is still "-----BEGIN ENCRYPTED PRIVATE KEY-----".

I was hoping to use a generated key for mosquitto TLS and mosquitto doesn't support encrypted private key files.
My work around is to use OpenSSL to remove the encryption:

openssl pkey -in encrypted_key.pem -passin "pass:" -out unencrypted_key.pem

Perhaps EvseSecurity should be updated to generate unencrypted key files when no password is specified (which would match expectation).

It is useful to be able to add additional items into the CSR so that additional use can be made of the certificate and key. A usecase would involve adding a subject alternative name (DNS name and IP address) and extended key usage (TLS server).

This topic is consider any additional CSR configuration that might be useful along with options as to how best to realize this enhanced capability.

Some possible implementations options:

1. Extend the existing approach and possibly expand the CSR interface with a struct parameter that can grow in the future
2. Call OpenSSL (openssl req -config ...) allowing a specific configuration file to be used allowing some settings of the command line

There are some example script that use OpenSSL to generate certificates for the unit tests that demonstrate how OpenSSL configuration could be used: example. CSRs could use similar approaches.

At the moment there is no detailed report on which test from within a testcase file has failed. Logs would be required to identify the specific test.

Wherever the API is present, the 3+ openssl API should be used, while also keeping backwards compatibility with openssl 1

I followed https://github.com/qwello/everest-core?tab=readme-ov-file#build--install on a fresh installation of Ubuntu 20.04.5. I see the following compile error:

[0/798] Building CXX object _deps/everest-framework-build/lib/CMakeFiles/framework.dir/config.cpp.o

[271/798] Building CXX object _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/crypto/openssl/openssl_supplier.cpp.o
FAILED: _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/crypto/openssl/openssl_supplier.cpp.o
/usr/bin/c++  -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_LOG_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_THREAD_DYN_LINK -DLIBEVSE_CRYPTO_SUPPLIER_OPENSSL -I/home/odroid/holger/everest/everest-workspace/libevse-security/include -I/home/odroid/holger/everest/everest-workspace/liblog/include -std=gnu++17 -MD -MT _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/crypto/openssl/openssl_supplier.cpp.o -MF _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/crypto/openssl/openssl_supplier.cpp.o.d -o _deps/libevse-security-build/lib/evse_security/CMakeFiles/evse_security.dir/crypto/openssl/openssl_supplier.cpp.o -c /home/odroid/holger/everest/everest-workspace/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp
In file included from /home/odroid/holger/everest/everest-workspace/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp:5:
/home/odroid/holger/everest/everest-workspace/libevse-security/include/evse_security/detail/openssl/openssl_providers.hpp:12:10: fatal error: openssl/provider.h: No such file or directory
   12 | #include <openssl/provider.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.

I have openssl-dev installed:

sudo apt install libssl-dev
[sudo] password for odroid:
Reading package lists... Done
Building dependency tree
Reading state information... Done
libssl-dev is already the newest version (1.1.1f-1ubuntu2.20).
0 upgraded, 0 newly installed, 0 to remove and 319 not upgraded.

What can I do to fix this?

Describe the problem

At the moment the library crashes quite a lot on minor issues related to the state or on executing operations. It should handle the case properly.

Some interface functions also need a better error handling/reporting, like the 'generate CSR' interface call.

Describe your solution

Handle all the possible crash cases and modify the interface to fit the new handling .

Additional context

No response

Describe the problem

According to the OCPP2.0.1 specification we have to support multiple SECC leaf certificates for a charging station. At the moment the concept supports having multiple leaf certificates installed, but they are not dedicated to individual EVSEs.

When a CSR is generated, the Common Name (CN) field of the certificate shall be set to the ISO15118SeccId of the EVSE. In case of multiple EVSEs per charging station, this variable is unique for every EVSE. The CN is already an argument of the generate_csr function so this does not need to change.

The get_key_pair function does currently return the most recent certificate that is already valid and the respective key, without differentiating between the EVSE it was issued for.

Describe your solution

Options:

1. Extend the get_key_pair function by an argument that represents the ISO15118SeccId.
2. Seperate the get_key_pair function into two different functions: One for CSMS and one for V2G.

The key pair that is returned shall match this id.

Additional context

The trigger of generating the CSR is outside the scope of this library. Libraries like libocpp need to take care of renewing certificates in case they are expired and calling the generate_csr function with the correct arguments

Describe the bug

[ 51%] Linking CXX static library libslac_fsm_ev.a
[ 51%] Built target slac_fsm_ev
/usr/bin/ld: ../lib/libcurl.a(openssl.c.o): in function Curl_ossl_certchain': openssl.c:(.text+0xcb0): undefined reference to EVP_PKEY_get_id'
/usr/bin/ld: openssl.c:(.text+0xd1b): undefined reference to EVP_PKEY_get_bn_param' /usr/bin/ld: openssl.c:(.text+0xd35): undefined reference to EVP_PKEY_get_bn_param'
/usr/bin/ld: openssl.c:(.text+0xea7): undefined reference to EVP_PKEY_get_bn_param' /usr/bin/ld: openssl.c:(.text+0xec1): undefined reference to EVP_PKEY_get_bn_param'
/usr/bin/ld: openssl.c:(.text+0xedb): undefined reference to EVP_PKEY_get_bn_param' /usr/bin/ld: ../lib/libcurl.a(openssl.c.o):openssl.c:(.text+0xef5): more undefined references to EVP_PKEY_get_bn_param' follow
/usr/bin/ld: ../lib/libcurl.a(openssl.c.o): in function cert_stuff': openssl.c:(.text+0x2f13): undefined reference to EVP_PKEY_get_id'
/usr/bin/ld: ../lib/libcurl.a(openssl.c.o): in function verifystatus': openssl.c:(.text+0x47ad): undefined reference to SSL_get1_peer_certificate'
/usr/bin/ld: ../lib/libcurl.a(openssl.c.o): in function populate_x509_store': openssl.c:(.text+0x567c): undefined reference to X509_STORE_load_file'
/usr/bin/ld: openssl.c:(.text+0x570b): undefined reference to X509_STORE_load_path' /usr/bin/ld: ../lib/libcurl.a(openssl.c.o): in function servercert':
openssl.c:(.text+0x77ae): undefined reference to `SSL_get1_peer_certificate'
collect2: error: ld returned 1 exit status
make[2]: *** [_deps/libcurl-build/src/CMakeFiles/curl.dir/build.make:722: _deps/libcurl-build/src/curl] Error 1
make[1]: *** [CMakeFiles/Makefile2:4228: _deps/libcurl-build/src/CMakeFiles/curl.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

After I installed openssl 3, I used v0.7.0 to compile, but the compilation reported an error. The EVP_PKEY_get_id function could not be found, and it seemed that libcurl could not find this function. Should I change the version of libcurl?

To Reproduce

No response

Anything else?

No response

Certain test-cases for expired certificates are required, must have some functionality to generate a required amount of expired certificates at runtime and execute the tests.

Describe the bug

I'm trying to connect EVerest to a Security Profile 3 CitrineOS websocket server and running into an issue I'm unable to diagnose.
Would really appreciate some help getting to the bottom of this 🙏

EVerest is logging:
2024-05-31 00:45:39.542208 [ERRO] ocpp:OCPP201 void ocpp::WebsocketBase::log_on_fail(const std::error_code&, const boost::system::error_code&, int) :: Failed to connect to websocket server, error_code: 2, reason: Underlying Transport Error, HTTP response code: 0, category: websocketpp.transport, transport error code: 1, Transport error category: asio.ssl.stream

From the server side, I see that the client has hung up. I can't find any details about what the above error specifically means.

Here is the output of openssl s_client -connect using the certificates from EVerest's files to connect to CitrineOS's SP3 websocket server:

CONNECTED(00000003)
Can't use SSL_get_servername
depth=3 CN = V2GRootCA, O = EVerest, C = DE, DC = V2G
verify return:1
depth=2 CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G
verify return:1
depth=1 CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G
verify return:1
depth=0 CN = host.docker.internal, O = EVerest, C = DE, DC = CPO
verify return:1
---
Certificate chain
 0 s:CN = host.docker.internal, O = EVerest, C = DE, DC = CPO
   i:CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Mar 12 01:43:09 2024 GMT; NotAfter: Mar 10 01:43:09 2034 GMT
 1 s:CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G
   i:CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Mar 12 01:43:09 2024 GMT; NotAfter: Mar 10 01:43:09 2034 GMT
 2 s:CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G
   i:CN = V2GRootCA, O = EVerest, C = DE, DC = V2G
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Mar 12 01:43:09 2024 GMT; NotAfter: Mar 10 01:43:09 2034 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIB6zCCAZGgAwIBAgICMDwwCgYIKoZIzj0EAwIwSDESMBAGA1UEAwwJQ1BPU3Vi
Q0EyMRAwDgYDVQQKDAdFVmVyZXN0MQswCQYDVQQGEwJERTETMBEGCgmSJomT8ixk
ARkWA1YyRzAeFw0yNDAzMTIwMTQzMDlaFw0zNDAzMTAwMTQzMDlaMFMxHTAbBgNV
BAMMFGhvc3QuZG9ja2VyLmludGVybmFsMRAwDgYDVQQKDAdFVmVyZXN0MQswCQYD
VQQGEwJERTETMBEGCgmSJomT8ixkARkWA0NQTzBZMBMGByqGSM49AgEGCCqGSM49
AwEHA0IABH4hdFZ4+OPvMSLfwcLxvGRflEk7I5zUfQhs9J55DXBo+iv74EtJI/Qg
kf1Cl2S1BK5lGb2o2XekeIYIHOyFIxOjYDBeMAwGA1UdEwEB/wQCMAAwDgYDVR0P
AQH/BAQDAgOIMB0GA1UdDgQWBBSRJ5Mlf4CqG2mbvHj3PE++7WnnpjAfBgNVHSME
GDAWgBSdZoihKocUHKu7g0HVL7/kHarXuzAKBggqhkjOPQQDAgNIADBFAiEAqxo/
vWSzHj/415lXYoD1lrh2HgaTS8BxOR5hY44g9KcCIDFHQ2v39OV6fSETzF5VFU2/
MblV+2toVvnyuDX5rM8v
-----END CERTIFICATE-----
subject=CN = host.docker.internal, O = EVerest, C = DE, DC = CPO
issuer=CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G
---
Acceptable client certificate CA names
CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G
CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2291 bytes and written 989 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

It appears that the handshake is good. EVerest appears to have all the correct settings from the logs. Please help pinpoint why the connection is dropped?

To Reproduce

A demo has been set up at: https://github.com/ChrisWeissmann/everest-demo/tree/feature/add-citrine-support

The following command fires up EVerest and CitrineOS, to connect using SP3: ./demo-iso15118-2-ac-plus-ocpp.sh -3 -c -r $(pwd) -b feature/citrine-support

Note: This demo works with MaEVe! So the certificate structure is not the issue, as the same certificates are used. MaEVe has the same output from openssl s_client -connect. Other chargers have been able to connect to CitrineOS via SP3 in the past. I am not sure in this case whether Citrine needs to correct something or EVerest. I can't investigate deeper without knowing more about the error EVerest is throwing.

Anything else?

No response

In order to limit disk usage that is unchecked at the moment the following measures will be in place:

• CSR timeout: if the private key of a CSR can not be paired with a certificate response within a certain configurable timeframe, the private key will be deleted. A monotonic clock will be used for independence of system time
• Size (MB) limit for certificates (configurable, with a default of 100MB), if the size limit is exceeded no further certificates will be installed
• Garbage collector function, that receives a 'correct' real time in order to check certificate validity and delete expired ones

In the future a configurable limit on individual certificates can be set, when used in pair with libocpp, that limits the certificate count.

Describe the problem

In the code of x509_hierarchy, it seems that a generalized tree is implemented by itself. Have you considered modifying it to use the generalized tree implementation in the library?

Describe your solution

In the code of x509_hierarchy, it seems that a generalized tree is implemented by itself. Have you considered modifying it to use the generalized tree implementation in the library?

Additional context

In the code of x509_hierarchy, it seems that a generalized tree is implemented by itself. Have you considered modifying it to use the generalized tree implementation in the library?