Security Profile 3 Connectivity Issue

[thanaParis]

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

[AssemblyJohn]

Hello!

Thank you for the feedback, we will look into as soon as possible. In the meantime try to compile with full logging inside the libwebsocket.cpp class (https://github.com/EVerest/libocpp/blob/9398212ad0f11136bb3cd253b9282f3618148392/lib/ocpp/common/websocket/websocket_libwebsockets.cpp#L430). Also a fuller log would help better.

Things that can be tried:

1. Disable server certificate verification ("variable_name": "VerifyCsmsCommonName") - set that to false
2. Check the certificate hierarchy that is set for EVerest