You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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
The text was updated successfully, but these errors were encountered:
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: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
The text was updated successfully, but these errors were encountered: