Closed ColinCGC closed 1 month ago
Hi @ColinCGC,
Thanks for submitting your question. I've taken a look at this and I agree that we definitely need to improve documentation about uploading certificates especially regarding certificate paths (they're currently not documented at all with the exception of one). Thus I'm not surprised that you're facing issues while trying to get your WB ready for accepting TLS connections. The upload procedure you're following looks fine so far. However you're likely getting errors due to incorrect certificate paths (see below for correct paths). Regarding your questions:
00 15
for the given example. The table not including the string length parameter is expected however as the string parameter is almost always preceeded by a length parameter. For details on this please refer to section 10.3.3 of the 2.17 User Manual. The certificate path in the example is just an example path and not the path that you want to use. The CPO certificates should be stored under fs/cert/v2g/own/shared and the MO certificate under fs/cert/v2g/trusted/mo. This is currently not documented, which we'll fix.I hope I could clarify your questions. The main thing that's currently keeping you from uploading the certificates is the wrong certificate path. If you upload the certificates to the correct paths instead it should work. If you have any questions left or need further guidance on how to get your WB ready for TLS, please feel free to ask!
Best regards, Niklas Stoffers
Thank you for your comments Niklas, very helpful, I will give it a go.
With the SDP question, it is of course correct that TLS is not offered, but what I meant was is the returned port value intentional - I had assumed the port for non-TLS TCP would be returned, not a placeholder (56789). Not a big deal, just curious.
Hi @ColinCGC,
Thanks for the clarification with the SDP. The TCP port that you've got is actually not a placeholder. The TCP port is being randomly generated (TLS port is always the random TCP port + 1). This is required by the ISO standard. That you've got exactly the port 56789 should just be a coincidence.
Best regards, Niklas Stoffers
This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.
Hi, I did manage to load certificates + key, and the WB seemed happy, returning a "Loaded" Certificate Status message status for each.
The EVCC is able to connect to the provided TCP port for TLS, but the WB is then not happy about something in the TLS Client Hello message, returning a "Handshake Failure" TLS Alert. I don't know if this is because of something wrong in the client hello message, or something with missing/wrong with the SECC WB TLS setup.
Wireshark log attached
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 105
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 101
Version: TLS 1.2 (0x0303)
Random: 64e73362eb04e0c3b50117cd92d9a7e14f260dcc0b8c21400165104754eaa5be
Session ID Length: 0
Cipher Suites Length: 2
Cipher Suites (1 suite)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (0xc025)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 58
Extension: signature_algorithms (len=4)
Type: signature_algorithms (13)
Length: 4
Signature Hash Algorithms Length: 2
Signature Hash Algorithms (1 algorithm)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: ECDSA (3)
Extension: ec_point_formats (len=2)
Extension: trusted_ca_keys (len=23)
Type: trusted_ca_keys (3)
Length: 23
Data: 0015017bdc63125d77f0ad7feb700d62574e8e8f1cf436
Extension: supported_groups (len=4)
Type: supported_groups (10)
Length: 4
Supported Groups List Length: 2
Supported Groups (1 group)
Supported Group: secp256r1 (0x0017)
Extension: max_fragment_length (len=1)
Type: max_fragment_length (1)
Length: 1
Maximum Fragment Length: 1024 (2)
Extension: truncated_hmac (len=0)
Type: truncated_hmac (4)
Length: 0
Data:
Hi @ColinCGC,
Thanks for your response. I'm glad that for now you're able to load the certificates onto the Whitebeet. I'll take a look at what's going wrong with the TLS handshake and come back to you once I found something out.
Best regards, Niklas Stoffers
Hi @ColinCGC,
I've taken a look at your Client Handshake. You're trying to connect using the TLS cipher suite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256. However unfortunately we only support ephemeral ECDH. Please try connecting with a different cipher suite such as TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.
Please let me know if you're able to proceed further with the suggested solution. If you have any more questions, feel free to ask!
Best regards, Niklas Stoffers
Thank you - I have tried that already though (with either and both) and it makes no difference.
My assumption was that it is something with the extensions, either something I'm sending that the WB doesn't like or an extension it expects but isn't seeing (like OCSP), but I'm only guessing...
Hi @ColinCGC,
Okay, that's strange. Could you please capture a Wireshark log trying to connect with cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256? Furthermore the WB should also give some hints on what's going wrong in its UART output. Could you please share the UART as well?
Best regards, Niklas Stoffers
Sure, section of UART output is below - it does look a little odd.
[ 112.612] [NOTICE] V2GSVC: Starting in EVSE mode. [ 112.612] [NOTICE] V2GAPP: Listen was started [ 112.618] [NOTICE] V2GSVC: TCP: Listen on port 55156 for non-TLS [ 112.619] [NOTICE] V2GSVC: TCP: Listen on port 55157 for TLS [ 115.157] [NOTICE] V2GSVC: TCP: Listen on port 55156 for non-TLS [ 115.158] [NOTICE] V2GSVC: TCP: Listen on port 55157 for TLS [ 115.164] [WARN ] V2GSVC: TCP: Tried to start but already started! [ 115.165] [NOTICE] V2GSVC: TCP: Client disconnected or connection closed by server [ 115.165] [WARN ] V2GSVC: TCP: Tried to start but already started! [ 115.166] [WARN ] V2GSVC: TCP: Tried to stop but already stopped! [ 115.172] [NOTICE] V2GSVC: TCP: Listen on port 55156 for non-TLS [ 115.173] [NOTICE] V2GSVC: TCP: Listen on port 55157 for TLS
Wireshark: tls_hsfail_ecdhe.zip
TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 109 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 105 Version: TLS 1.2 (0x0303) Random: 64e73362ee96acd5e863577679f5d3788e27d88a5f713885570f784fc5d54f9a Session ID Length: 0 Cipher Suites Length: 2 Cipher Suites (1 suite) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 62 Extension: signature_algorithms (len=4) Type: signature_algorithms (13) Length: 4 Signature Hash Algorithms Length: 2 Signature Hash Algorithms (1 algorithm) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: trusted_ca_keys (len=23) Type: trusted_ca_keys (3) Length: 23 Data: 0015017bdc63125d77f0ad7feb700d62574e8e8f1cf436 Extension: supported_groups (len=4) Type: supported_groups (10) Length: 4 Supported Groups List Length: 2 Supported Groups (1 group) Supported Group: secp256r1 (0x0017) Extension: max_fragment_length (len=1) Type: max_fragment_length (1) Length: 1 Maximum Fragment Length: 1024 (2) Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 [JA3 Fullstring: 771,49187,13-11-22-3-10-1-23,23,0] [JA3: f3d934a61109e5bc0de13920087b2973]
Hi @ColinCGC,
I've taken a look at your issue again. The whitebeet will only close the tcp connection with a handshake failure if either the cipher suite or the signature scheme is unsupported or it's not able to load the correct certificates. In this case this has to be an issue with the certificates as we support both the cipher suite and signature scheme that were offered during the client hello message. Could you please recheck the certificates that you've uploaded to the whitebeet? This is a little hard to debug without having access to your concrete setup.
Best regards and thanks for your patience, Niklas Stoffers
This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.
This issue was closed because it has been inactive for 7 days since being marked as stale. If your issue still persists, feel free to reopen!
Using EVSE v02_01_00, SPI interface. Manual rev 2.17.
I am attempting to configure the wb to accept a TLS connection. I saw in another post one needs to first upload certificates as per the process shown in section 21.8.12, which I am following, but I am running into whitebeet issues and need some guidance.
Questions:
Something else I noticed, if I (the EVCC) request TLS during SDP, I get a response indicating no TLS and a port of 56789![image](https://github.com/Sevenstax/FreeV2G/assets/72616875/5172f2e2-2da3-48eb-a4b7-b46714155da4)
Thank you, Colin