Enable Security Profile 3 (TLS with Client Side Certificates)

[shankari]

In PR #22, we created a one-line demo that allowed us to test end to end charging with OCPP 2.0.1. However it only supports Basic Auth

This issue will track the changes required to change it to support Security Profile 3 (2 in MaEVe since it starts with 0), using a client certificate for authentication.

It will temporarily use a forked version of MaEVe that has hardcoded certificates from an adversarial PKI testing event. Eventually, we will want to have the demo use an open CA and non-proprietary certificates, but make it easy to configure so that testers can easily use proprietary certificates or implementations.

@jhoshiko @sahabulh @crr-snl for visibility

[sahabulh]

@shankari , @jhoshiko please check the Zulip topic Enable OCPP 2.0.1 Security Profile 2 and 3. I was able to make it work for both security profile 2 and 3 for release 2023.10.0. For 2024.2.0, I am getting an error. I will discuss it with the EVerest devs later.

It is to be noted that I didn't use the one liner MRE which is giving the same error. We continue discussing in the Zulip chat why this is happening for the MRE.

[sahabulh]

As it is working for 2023.10.0 built from scratch, we might want to bump down to that and try again.

[shankari]

Glad to see the discussion around cert structures. The single line MRE will obviously not work unless you change the script; have you tried after changing the script?

[sahabulh]

I changed the MaEVe cert generation script. Just added this at the end of all the copying:

cat config/certificates/csms.pem config/certificates/cpo_sub_ca1.pem config/certificates/cpo_sub_ca2.pem > config/certificates/csms.pem

[sahabulh]

As it is working for 2023.10.0 built from scratch, we might want to bump down to that and try again.

@shankari , can we try this? For some reason, I can't pull the old release. I cloned the repo, changed the scripts, .env and the dockerfile, but when I run it, it still pulls the 0.0.12 images.

What do I need to do to downgrade?

[shankari]

@sahabulh Great! Can you submit that as a PR? That would make it easier for others to reproduce/build on this work

[shankari]

@sahabulh

can we try this? For some reason, I can't pull the old release. I cloned the repo, changed the scripts, .env and the dockerfile, but when I run it, it still pulls the 0.0.12 images.

Changed the scripts in which way? What are the messages that you get when you run?

The docker-compose reads the version from the TAG environment variable, which is set in .env Is it in the correct directory? Have you checked the docker compose documentation? (e.g. docker compose config)

[shankari]

I would also like to understand how this worked with the Mobility OpenHouse python based implementation.

It is general best practice to have a bundled certificate chain while using SSL with webservers, and I have encountered it earlier. So I flagged the bundling as an issue earlier https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987500724 and https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987625942

but I assumed that the changes (if any) would need to be on the EVSE side since the same CSMS was working with a different client.

Action items:

• We need to understand what MaEVe expects wrt bundling and whether bundling is the recommended best practice for all clients (it should be)
• At least for EVerest, the CSMS cert should have the FQDN of the CSMS host (which is also the norm in SSL for webservers). I am not sure how the Eonti/SAE certs will work for this, since they appear to have a hardcoded CN of USEMAC00000004. We need to follow up with SAE about this, unless there are other certificates that we are not using. https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987376078

$ openssl verify -show_chain -CAfile config/certificates/root-V2G-cert.pem -untrusted config/certificates/cpo_sub_ca2.pem config/certificates/csms.pem
config/certificates/csms.pem: OK
Chain:
depth=0: C = US, O = Sandia, OU = EV Department, CN = USEMAC00000004 (untrusted)
depth=1: C = US, O = EV Charging PKI, OU = TEST MO Sub-CA, CN = P-256 TEST Tier 1 MO Sub-CA (untrusted)
depth=2: C = US, O = EV Charging PKI, DC = EVCPKI, OU = TEST Root CA, CN = P-256 TEST Root CA

[sahabulh]

@sahabulh Great! Can you submit that as a PR? That would make it easier for others to reproduce/build on this work

I will submit a PR but I am afraid I will not be able to do that before Friday night. I need to work on my PhD study. Sorry! But I will give some written description below.

Changed the scripts in which way? What are the messages that you get when you run?

For the script demo-iso15118-2-ac-plus-ocpp201.sp2.sh, I just edited it to turn off the load balancer. I don't think it matters as the problem is that I can't pull release 2023.10.0.

The docker-compose reads the version from the TAG environment variable, which is set in .env Is it in the correct directory? Have you checked the docker compose documentation? (e.g. docker compose config)

I have changed the tag to 0.0.11 in the .env file. I have also changed the Everest version in the manager/Dockerfile to 2023.10.0. But it is still pulling 0.0.12.

[shankari]

@sahabulh

I have changed the tag to 0.0.11 in the .env file. I have also changed the Everest version in the manager/Dockerfile to 2023.10.0. But it is still pulling 0.0.12.

Where did you change the tag? Note that the script checks out another copy of the everest-demo repo - it is a single-line demo because it does not require the everest-demo code to be checked out before it is run. So changing the local .env file won't accomplish anything

[sahabulh]

I would also like to understand how this worked with the Mobility OpenHouse python based implementation.

I figured it out. The reason the python client code was working although MaEVe wasn't sending the intermediate CAs is that the certificate verification wasn't turned on for the client. So, the although the CSMS was verifying the charger's certs, the charger wasn't verifying the csms's certs. And that's why it didn't throw the error. After I turned the certificate verification on for the OCPP client (charger), it is working perfectly with the chain (leaf + ca2 + ca1) and doesn't work with the single leaf.

It is general best practice to have a bundled certificate chain while using SSL with webservers, and I have encountered it earlier. So I flagged the bundling as an issue earlier https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987500724 and https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987625942

Yeah, the best practice is that both the client and the server send their respective chains.

but I assumed that the changes (if any) would need to be on the EVSE side since the same CSMS was working with a different client.

As mentioned before, there was an error in the python client code.

We need to understand what MaEVe expects wrt bundling and whether bundling is the recommended best practice for all clients (it should be)

I agree. But in both cases (Mobility House and Everest), the client is sending only the leaf. I think the server assumes that the subca's for the charger chain and it's own chain are the same? In reality, they can be different. Only the root is required to be the same. What is your thought on this?

At least for EVerest, the CSMS cert should have the FQDN of the CSMS host (which is also the norm in SSL for webservers). I am not sure how the Eonti/SAE certs will work for this, since they appear to have a hardcoded CN of USEMAC00000004. We need to follow up with SAE about this, unless there are other certificates that we are not using.

They actually didn't hard code that. I did that when I issued the cert myself. Remember, that certificate is actually the Contract Certificate (I used same cert everywhere for simplicity) and they are required to have the EMAID as their CN. But in reality, the OCPP server will have a different certificate and it can contain the suitable FQDN as the CN. But we will have to make sure that the testers generate their certs properly.

[sahabulh]

@sahabulh

I have changed the tag to 0.0.11 in the .env file. I have also changed the Everest version in the manager/Dockerfile to 2023.10.0. But it is still pulling 0.0.12.

Where did you change the tag? Note that the script checks out another copy of the everest-demo repo - it is a single-line demo because it does not require the everest-demo code to be checked out before it is run. So changing the local .env file won't accomplish anything

I figured this out also. I forked the demo repo, made a commit with those changes and pointed the script to my fork. Now, the one liner correctly pulls the 0.0.11 images. But, now I have another issue. Everest freezes in the middle of boot up:

0c5fabb5534e:/workspace# sh ./build/run-scripts/run-sil-ocpp201.sh
2024-03-14 18:10:49.927254 [INFO] manager          ::   ________      __                _   
2024-03-14 18:10:49.927302 [INFO] manager          ::  |  ____\ \    / /               | |  
2024-03-14 18:10:49.927314 [INFO] manager          ::  | |__   \ \  / /__ _ __ ___  ___| |_ 
2024-03-14 18:10:49.927322 [INFO] manager          ::  |  __|   \ \/ / _ \ '__/ _ \/ __| __|
2024-03-14 18:10:49.927331 [INFO] manager          ::  | |____   \  /  __/ | |  __/\__ \ |_ 
2024-03-14 18:10:49.927339 [INFO] manager          ::  |______|   \/ \___|_|  \___||___/\__|
2024-03-14 18:10:49.927347 [INFO] manager          :: 
2024-03-14 18:10:49.927353 [INFO] manager          :: Using MQTT broker mqtt-server:1883
2024-03-14 18:10:49.943736 [INFO] manager          :: Loading config file at: /ext/source/config/config-sil-ocpp201.yaml
2024-03-14 18:10:50.458294 [INFO] manager          :: - Types loaded in [21ms]
2024-03-14 18:10:50.458328 [INFO] manager          :: - Types validated [478ms]
2024-03-14 18:10:50.459226 [INFO] manager          :: - Errors loaded in [0ms]
2024-03-14 18:10:50.459244 [INFO] manager          :: - Errors validated [0ms]
2024-03-14 18:10:50.671974 [INFO] manager          :: Config loading completed in 744ms
2024-03-14 18:10:50.675590 [INFO] everest_ctrl     :: Launching controller service on port 8849
2024-03-14 18:11:07.743742 [INFO] api:API          :: Module api initialized [16595ms]
2024-03-14 18:11:07.944847 [INFO] evse_manager_2:  :: Module evse_manager_2 initialized [17255ms]
2024-03-14 18:11:08.549382 [INFO] grid_connection  :: Module grid_connection_point initialized [17299ms]
2024-03-14 18:11:08.946510 [INFO] energy_manager:  :: Module energy_manager initialized [18197ms]
2024-03-14 18:11:09.443236 [INFO] token_provider_  :: Module token_provider_1 initialized [17793ms]
2024-03-14 18:11:09.649076 [INFO] auth:Auth        :: Module auth initialized [18895ms]
2024-03-14 18:11:10.250232 [INFO] evse_security:E  :: Module evse_security initialized [19101ms]
2024-03-14 18:11:10.544756 [INFO] evse_manager_1:  :: Module evse_manager_1 initialized [19595ms]
2024-03-14 18:11:10.550609 [INFO] system:System    :: Module system initialized [19101ms]

2024-03-14 18:11:10.943216 [INFO] iso15118_charge  :: TCP server on eth0 is listening on port [fe80::42:acff:fe19:3%1961]:61341

2024-03-14 18:11:10.943498 [INFO] iso15118_charge  :: TLS server on eth0 is listening on port [fe80::42:acff:fe19:3%1961]:64109

2024-03-14 18:11:10.943663 [INFO] iso15118_charge  :: SDP socket setup succeeded
2024-03-14 18:11:10.944424 [INFO] iso15118_charge  :: Module iso15118_charger initialized [19794ms]
2024-03-14 18:11:11.645237 [INFO] ocpp:OCPP201     :: Module ocpp initialized [20797ms]
2024-03-14 18:11:11.658793 [INFO] persistent_stor  :: Module persistent_store initialized [20511ms]

It stays like that indefinitely. But it doesn't always freeze at the same point. I think I will have to create a PR for this.

[shankari]

@sahabulh https://github.com/EVerest/everest-demo/pull/28 You need to use an even older tag

[activeshadow]

I've managed to get past all the above errors based on the advise from both this issue and the related Zulip chats. Now I end up in an endless loop of failed websocket connection attempts. They seem to be different errors than what @jhoshiko was seeing regarding websocket errors.

2024-03-15 23:07:55.424126 [INFO] manager          :: 🚙🚙🚙 All modules are initialized. EVerest up and running [9743ms] 🚙🚙🚙
2024-03-15 23:07:55.425043 [INFO] ocpp:OCPP201     :: OCPP certificates path: /workspace/dist/etc/everest/certs
2024-03-15 23:07:55.628672 [INFO] ocpp:OCPP201     :: Established connection to device model database successfully: "/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db"
2024-03-15 23:07:55.632904 [INFO] ocpp:OCPP201     :: Successfully retrieved Device Model from DeviceModelStorage
2024-03-15 23:07:55.655301 [INFO] ocpp:OCPP201     :: Logging OCPP messages to log file: /tmp/everest_ocpp_logs/2024-03-15T23:07:55.655Z.log
2024-03-15 23:07:55.655381 [INFO] ocpp:OCPP201     :: Logging OCPP messages to html file: /tmp/everest_ocpp_logs/2024-03-15T23:07:55.655Z.html
2024-03-15 23:07:55.655419 [INFO] ocpp:OCPP201     :: Logging SecurityEvents to file
2024-03-15 23:07:55.655960 [INFO] ocpp:OCPP201     :: TxStartPoint from device model: PowerPathClosed
2024-03-15 23:07:55.659610 [INFO] evse_manager_1:  :: Max AC hardware capabilities: 32A/3ph
2024-03-15 23:07:55.698466 [INFO] evse_manager_2:  :: Ignoring BSP Event, BSP is not enabled yet.
2024-03-15 23:07:55.701660 [INFO] evse_manager_2:  :: Max AC hardware capabilities: 32A/3ph
2024-03-15 23:07:55.704230 [INFO] evse_manager_1:  :: Ignoring BSP Event, BSP is not enabled yet.
2024-03-15 23:07:55.829815 [INFO] evse_manager_1:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-15 23:07:55.871536 [INFO] ocpp:OCPP201     :: EVSE 1 ready.
2024-03-15 23:07:55.872005 [INFO] evse_manager_2:  :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀
2024-03-15 23:07:55.913433 [INFO] ocpp:OCPP201     :: EVSE 2 ready.
2024-03-15 23:07:55.913498 [INFO] ocpp:OCPP201     :: All EVSE ready. Starting OCPP2.0.1 service
2024-03-15 23:07:56.078295 [INFO] ocpp:OCPP201     :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 2
2024-03-15 23:07:56.096913 [ERRO] manager         void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request.
2024-03-15 23:07:56.137454 [INFO] evse_manager_2:  :: All errors cleared
2024-03-15 23:07:56.138284 [ERRO] manager         void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request.
2024-03-15 23:07:56.177670 [INFO] evse_manager_1:  :: All errors cleared
2024-03-15 23:07:56.163789 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-15 23:07:56.220836 [ERRO] manager         void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request.
2024-03-15 23:07:56.261620 [INFO] evse_manager_2:  :: All errors cleared
2024-03-15 23:07:56.270576 [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: 167772436, Transport error category: asio.ssl
2024-03-15 23:07:56.270639 [INFO] ocpp:OCPP201     :: Reconnecting in: 2000ms, attempt: 1
2024-03-15 23:07:56.270955 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate
2024-03-15 23:07:56.302740 [ERRO] manager         void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request.
2024-03-15 23:07:56.312518 [INFO] ocpp:OCPP201     :: libocpp: Updating OCSP cache on 0 certificates
2024-03-15 23:07:56.312578 [INFO] ocpp:OCPP201     :: libocpp: Done updating OCSP cache
2024-03-15 23:07:56.343737 [INFO] evse_manager_1:  :: All errors cleared
2024-03-15 23:07:56.345695 [ERRO] manager         void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request.
2024-03-15 23:07:56.386635 [INFO] evse_manager_2:  :: All errors cleared
2024-03-15 23:07:56.426806 [ERRO] manager         void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request.
2024-03-15 23:07:56.467655 [INFO] evse_manager_1:  :: All errors cleared
2024-03-15 23:07:58.272277 [INFO] ocpp:OCPP201     :: Reconnecting to TLS websocket at uri: wss://host.docker.internal/ws/cp001 with security profile: 2
2024-03-15 23:07:58.355700 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-15 23:07:58.460303 [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: 167772436, Transport error category: asio.ssl
2024-03-15 23:07:58.460361 [INFO] ocpp:OCPP201     :: Reconnecting in: 4000ms, attempt: 2
2024-03-15 23:08:02.464155 [INFO] ocpp:OCPP201     :: Reconnecting to TLS websocket at uri: wss://host.docker.internal/ws/cp001 with security profile: 2
2024-03-15 23:08:02.547640 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-15 23:08:02.694339 [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: 167772436, Transport error category: asio.ssl
2024-03-15 23:08:02.694407 [INFO] ocpp:OCPP201     :: Reconnecting in: 8000ms, attempt: 3
2024-03-15 23:08:10.702122 [INFO] ocpp:OCPP201     :: Reconnecting to TLS websocket at uri: wss://host.docker.internal/ws/cp001 with security profile: 2
2024-03-15 23:08:10.745746 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-15 23:08:10.851100 [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: 167772436, Transport error category: asio.ssl
2024-03-15 23:08:10.851144 [INFO] ocpp:OCPP201     :: Closing TLS websocket.
2024-03-15 23:08:10.851158 [ERRO] ocpp:OCPP201    virtual void ocpp::WebsocketTLS::close(websocketpp::close::status::value, const std::string&) :: Error initiating close of TLS websocket: invalid state
2024-03-15 23:08:10.851173 [WARN] ocpp:OCPP201    ocpp::v201::ChargePoint::init_websocket()::<lambda(websocketpp::close::status::value)> :: Closed websocket of NetworkConfigurationPriority: 1 which is configurationSlot: 1
2024-03-15 23:08:12.853934 [INFO] ocpp:OCPP201     :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 2
2024-03-15 23:08:12.936590 [DEBG] ocpp:OCPP201     :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-03-15 23:08:13.042483 [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: 167772436, Transport error category: asio.ssl
2024-03-15 23:08:13.042573 [INFO] ocpp:OCPP201     :: Reconnecting in: 2000ms, attempt: 1

I made a few adjustments to the demo script to get past all the other errors in order to get to this one.

diff --git a/demo-iso15118-2-ac-plus-ocpp201.sp2.sh b/demo-iso15118-2-ac-plus-ocpp201.sp2.sh
index 88934dc..4b2d793 100755
--- a/demo-iso15118-2-ac-plus-ocpp201.sp2.sh
+++ b/demo-iso15118-2-ac-plus-ocpp201.sp2.sh
@@ -42,18 +42,19 @@ cp everest-demo/manager/cached_certs_correct_name.tar.gz maeve-csms
 pushd maeve-csms

 echo "Copying certs into ${DEMO_DIR}/maeve-csms/config/certificates"
-tar xzvf cached_certs_correct_name.tar.gz
-cp dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem config/certificates/root-V2G-cert.pem
-cp dist/etc/everest/certs/ca/csms/CPO_SUB_CA1.pem config/certificates/cpo_sub_ca1.pem
-cp dist/etc/everest/certs/ca/csms/CPO_SUB_CA2.pem config/certificates/cpo_sub_ca2.pem
-cp dist/etc/everest/certs/client/csms/CSMS_LEAF.pem config/certificates/csms.pem
+tar xf cached_certs_correct_name.tar.gz
+cat dist/etc/everest/certs/client/csms/CSMS_LEAF.pem \
+    dist/etc/everest/certs/ca/csms/CPO_SUB_CA2.pem \
+    dist/etc/everest/certs/ca/csms/CPO_SUB_CA1.pem \
+  > config/certificates/csms.pem
 cp dist/etc/everest/certs/client/csms/CSMS_LEAF.key config/certificates/csms.key
-cp dist/etc/everest/certs/client/csms/CPO_SUB_CA1.key config/certificates/cpo_sub_ca1.key
-cp dist/etc/everest/certs/client/csms/CPO_SUB_CA2.key config/certificates/cpo_sub_ca2.key
-cat config/certificates/cpo_sub_ca1.pem config/certificates/cpo_sub_ca2.pem > config/certificates/trust.pem
+cp dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem config/certificates/root-V2G-cert.pem

 echo "Validating that the certificates are set up correctly"
-openssl verify -show_chain -CAfile config/certificates/root-V2G-cert.pem -untrusted config/certificates/trust.pem config/certificates/csms.pem
+openssl verify -show_chain \
+  -CAfile config/certificates/root-V2G-cert.pem \
+  -untrusted config/certificates/csms.pem \
+  config/certificates/csms.pem

 echo "Starting the CSMS"
 docker compose up -d
@@ -84,8 +85,8 @@ docker exec everest-ac-demo-manager-1 /bin/bash -c "tar xzvf cached_certs_correc

 echo "Configured everest certs, validating that the chain is set up correctly"
 docker exec everest-ac-demo-manager-1 /bin/bash -c "openssl verify -show_chain -CAfile dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem --untrusted dist/etc/everest/certs/ca/csms/CPO_SUB_CA1.pem --untrusted dist/etc/everest/certs/ca/csms/CPO_SUB_CA2.pem dist/etc/everest/certs/client/csms/CSMS_LEAF.pem"
-echo "Copying bundle over to root (confusing!) https://github.com/EVerest/everest-demo/issues/25#issuecomment-1988895630"
-docker exec everest-ac-demo-manager-1 /bin/bash -c "cp dist/etc/everest/certs/ca/v2g/V2G_CA_BUNDLE.pem dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"
+# echo "Copying bundle over to root (confusing!) https://github.com/EVerest/everest-demo/issues/25#issuecomment-1988895630"
+# docker exec everest-ac-demo-manager-1 /bin/bash -c "cp dist/etc/everest/certs/ca/v2g/V2G_CA_BUNDLE.pem dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem"

 echo "Copying device DB, configured to SecurityProfile: 2"
 docker cp manager/device_model_storage_maeve_sp2.db everest-ac-demo-manager-1:/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db

Has anyone else experienced the endless loop of WebSocket "Underlying Transport Error" errors?

/cc @shankari @sahabulh

[activeshadow]

Now that I think about it more, perhaps it's the same cert CN / DNS issue mentioned previously, having to do with the host.docker.internal domain name.

I'll do some digging later to better orient myself with how the charger's occp client knows what address to use to connect to the csms. For example, is that a config option or does it use the CN from the csms server cert?

[shankari]

@activeshadow

Has anyone else experienced the endless loop of WebSocket "Underlying Transport Error" errors?

The current MRE does not have this error. Maybe you could generate an alternate MRE that outlines how you are getting this error. As you can see from the updates here, the difference between success and failure is the way that the certificates are configured, and it is hard to reproduce/debug without knowing that information.

I'll do some digging later to better orient myself with how the charger's occp client knows what address to use to connect to the csms. For example, is that a config option or does it use the CN from the csms server cert?

Please see prior issue comments on how the csmsURL is set in the device DB using SQL update

[shankari]

@sahabulh wrt https://github.com/EVerest/everest-demo/issues/25#issuecomment-1987464746, where did you get the sub_ca pair from?

I originally thought that they were from EonTI, but I just got access to the certs there and their sub CA cert does not match the checked in values. I note from https://github.com/EVerest/everest-demo/issues/25#issuecomment-1998085952 that you issued some of the certs yourself.

Are the versions that are checked in certs that you issued, or the ones from EonTI? And if from EonTI, for which test case?

[activeshadow]

The current MRE does not have this error. Maybe you could generate an alternate MRE that outlines how you are getting this error. As you can see from the updates here, the difference between success and failure is the way that the certificates are configured, and it is hard to reproduce/debug without knowing that information.

@shankari I've done some additional digging and see some service connections I had missed. I'll make a couple of additional changes to my local configs to get this demo example working further. More to come ASAP.

[shankari]

@activeshadow sounds good. I hope you saw the existing MRE https://github.com/EVerest/everest-demo/pull/29 and the fixes outlined after that in both the Zulip Chat and the issue. @sahabulh has the setup working on his laptop and plans to update the MRE to actually work today, so you might want to coordinate with him as well.

[activeshadow]

@activeshadow sounds good. I hope you saw the existing MRE https://github.com/EVerest/everest-demo/pull/29 and the fixes outlined after that in both the Zulip Chat and the issue. @sahabulh has the setup working on his laptop and plans to update the MRE to actually work today, so you might want to coordinate with him as well.

Yes @shankari that's the one I've been working from, thank you! @sahabulh and I are already coordinating so we should be good. 👍🏻

[activeshadow]

@shankari please see this commit on my fork of the everest-demo repo for a new MRE.

@sahabulh and I have both confirmed that it seems to be working, though we're both wondering why no OCPP logs are being generated when a car charging session is initiated in the Node-RED UI.

I will submit a PR for the MRE once I'm back on my laptop later. In the meantime I wanted you to be able to test it as well if you're interested in doing so.

Note that this MRE is using my fork of Maeve with the load balancer removed. It was giving me some trouble and I wanted to remove it from the equation since it's not part of what we were debugging here anyway. I know that @sahabulh has a fork of Maeve also that he's made some necessary changes to so at some point we'll just need to switch over to that one.

Also note that @sahabulh is now going to work on testing security profile 3 since this one is using security profile 2 (at least we think it is anyway).

[sahabulh]

@activeshadow @shankari I have submitted the pull request (#31) . Issues remaining are described there. But the server-client connection is good and the EV is able to charge using EIM.

[shankari]

@sahabulh thank you for the PR! I have added my comments to it. Can you also respond to my earlier comment about the provenance of the EonTI certs? https://github.com/EVerest/everest-demo/issues/25#issuecomment-2001084426 EonTI wanted to know which keypair was invalid. I think it is critical to understand how the currently generated EonTI certificates work or don't work, so that we can provide them with feedback in time.

[shankari]

@jhoshiko I just merged PRs to enable security profiles 2 and 3 (thanks to @activeshadow and @sahabulh for the MRE). Please try to run them and verify that they work for you as well.

[jhoshiko]

@shankari Ok, I've tested both demo-iso15118-2-ac-plus-ocpp201.sp2.sh and demo-iso15118-2-ac-plus-ocpp201.sp3.sh. Security profile 2 is working, but I am having some issues with security profile 3. Looks like the device DB is being copied correctly and the cert chain was validated:

Successfully copied 28.7kB to everest-ac-demo-manager-1:/workspace/
Configured everest certs, validating that the chain is set up correctly
dist/etc/everest/certs/client/csms/CSMS_LEAF.pem: OK
Chain:
depth=0: CN = host.docker.internal, O = EVerest, C = DE, DC = CPO (untrusted)
depth=1: CN = CPOSubCA2, O = EVerest, C = DE, DC = V2G (untrusted)
depth=2: CN = CPOSubCA1, O = EVerest, C = DE, DC = V2G (untrusted)
depth=3: CN = V2GRootCA, O = EVerest, C = DE, DC = V2G
Copying device DB, configured to SecurityProfile: 3
Successfully copied 83.5kB to everest-ac-demo-manager-1:/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db
Starting software in the loop simulation

However, it looks like I'm getting a connection error due to an invalid http status and the warning CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms"

Full Log

``` 2024-03-19 22:57:34.131767 [INFO] manager :: ________ __ _ 2024-03-19 22:57:34.132224 [INFO] manager :: | ____\ \ / / | | 2024-03-19 22:57:34.132244 [INFO] manager :: | |__ \ \ / /__ _ __ ___ ___| |_ 2024-03-19 22:57:34.132255 [INFO] manager :: | __| \ \/ / _ \ '__/ _ \/ __| __| 2024-03-19 22:57:34.132265 [INFO] manager :: | |____ \ / __/ | | __/\__ \ |_ 2024-03-19 22:57:34.132275 [INFO] manager :: |______| \/ \___|_| \___||___/\__| 2024-03-19 22:57:34.132303 [INFO] manager :: 2024-03-19 22:57:34.132333 [INFO] manager :: Using MQTT broker mqtt-server:1883 2024-03-19 22:57:34.150961 [INFO] everest_ctrl :: Launching controller service on port 8849 2024-03-19 22:57:34.164936 [INFO] manager :: Loading config file at: /ext/source/config/config-sil-ocpp201.yaml 2024-03-19 22:57:34.625108 [INFO] manager :: Config loading completed in 492ms 2024-03-19 22:57:42.259389 [INFO] system:System :: Module system initialized [6892ms] 2024-03-19 22:57:42.459028 [INFO] energy_manager: :: Module energy_manager initialized [7692ms] 2024-03-19 22:57:43.463513 [INFO] iso15118_charge :: TCP server on eth0 is listening on port [fe80::42:acff:fe16:3%127]:61341 2024-03-19 22:57:43.463657 [INFO] iso15118_charge :: TLS server on eth0 is listening on port [fe80::42:acff:fe16:3%127]:64109 2024-03-19 22:57:43.463734 [INFO] iso15118_charge :: SDP socket setup succeeded 2024-03-19 22:57:43.553075 [INFO] iso15118_charge :: Module iso15118_charger initialized [7789ms] 2024-03-19 22:57:44.255394 [INFO] auth:Auth :: Module auth initialized [9494ms] 2024-03-19 22:57:44.453316 [INFO] evse_security:E :: Module evse_security initialized [9596ms] 2024-03-19 22:57:44.456878 [INFO] grid_connection :: Module grid_connection_point initialized [9603ms] 2024-03-19 22:57:45.158546 [INFO] token_provider_ :: Module token_provider_1 initialized [9100ms] 2024-03-19 22:57:45.569595 [INFO] api:API :: Module api initialized [10805ms] 2024-03-19 22:57:45.772185 [INFO] evse_manager_2: :: Module evse_manager_2 initialized [10919ms] 2024-03-19 22:57:45.873134 [INFO] evse_manager_1: :: Module evse_manager_1 initialized [11017ms] 2024-03-19 22:57:45.953121 [INFO] persistent_stor :: Module persistent_store initialized [10386ms] 2024-03-19 22:57:46.653247 [INFO] ocpp:OCPP201 :: Module ocpp initialized [10388ms] 2024-03-19 22:57:53.265501 [INFO] manager :: 🚙🚙🚙 All modules are initialized. EVerest up and running [19142ms] 🚙🚙🚙 2024-03-19 22:57:53.266974 [INFO] ocpp:OCPP201 :: OCPP certificates path: /workspace/dist/etc/everest/certs 2024-03-19 22:57:53.275657 [INFO] ocpp:OCPP201 :: Established connection to device model database successfully: "/workspace/dist/share/everest/modules/OCPP201/device_model_storage.db" 2024-03-19 22:57:53.286663 [INFO] ocpp:OCPP201 :: Successfully retrieved Device Model from DeviceModelStorage 2024-03-19 22:57:53.553773 [INFO] evse_manager_1: :: Ignoring BSP Event, BSP is not enabled yet. 2024-03-19 22:57:53.555603 [INFO] evse_manager_2: :: Ignoring BSP Event, BSP is not enabled yet. 2024-03-19 22:57:53.578052 [INFO] ocpp:OCPP201 :: Logging OCPP messages to log file: /tmp/everest_ocpp_logs/2024-03-19T22:57:53.577Z.log 2024-03-19 22:57:53.578278 [INFO] ocpp:OCPP201 :: Logging OCPP messages to html file: /tmp/everest_ocpp_logs/2024-03-19T22:57:53.577Z.html 2024-03-19 22:57:53.578389 [INFO] ocpp:OCPP201 :: Logging SecurityEvents to file 2024-03-19 22:57:53.580527 [INFO] ocpp:OCPP201 :: TxStartPoint from device model: PowerPathClosed 2024-03-19 22:57:53.661005 [INFO] evse_manager_2: :: Max AC hardware capabilities: 32A/3ph 2024-03-19 22:57:53.671416 [INFO] evse_manager_1: :: Max AC hardware capabilities: 32A/3ph 2024-03-19 22:57:53.755241 [INFO] evse_manager_2: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀 2024-03-19 22:57:53.755639 [INFO] ocpp:OCPP201 :: EVSE 2 ready. 2024-03-19 22:57:53.802605 [INFO] evse_manager_1: :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀 2024-03-19 22:57:53.803340 [INFO] ocpp:OCPP201 :: EVSE 1 ready. 2024-03-19 22:57:53.803561 [INFO] ocpp:OCPP201 :: All EVSE ready. Starting OCPP2.0.1 service 2024-03-19 22:57:53.864858 [ERRO] manager void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request. 2024-03-19 22:57:53.867177 [INFO] evse_manager_2: :: All errors cleared 2024-03-19 22:57:53.871568 [INFO] ocpp:OCPP201 :: Connecting TLS websocket to uri: wss://host.docker.internal/ws/cp001 with security-profile 3 2024-03-19 22:57:53.888229 [INFO] evse_security:E :: TPM Key: false 2024-03-19 22:57:53.888991 [INFO] evse_security:E :: TPM Key: false 2024-03-19 22:57:53.890491 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms" 2024-03-19 22:57:53.891480 [INFO] ocpp:OCPP201 :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem" 2024-03-19 22:57:53.892270 [INFO] ocpp:OCPP201 :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key" 2024-03-19 22:57:53.908950 [ERRO] manager void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request. 2024-03-19 22:57:53.909877 [INFO] evse_manager_1: :: All errors cleared 2024-03-19 22:57:53.912992 [ERRO] manager void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request. 2024-03-19 22:57:53.913896 [INFO] evse_manager_1: :: All errors cleared 2024-03-19 22:57:53.929549 [ERRO] manager void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request. 2024-03-19 22:57:53.930387 [INFO] evse_manager_2: :: All errors cleared 2024-03-19 22:57:53.939265 [DEBG] ocpp:OCPP201 :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem 2024-03-19 22:57:53.979072 [ERRO] manager void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request. 2024-03-19 22:57:53.979364 [ERRO] manager void Everest::error::ErrorCommBridge::handle_request_clear_error(const json&) :: Error while clearing errors: No errors matched the request. 2024-03-19 22:57:53.980290 [INFO] evse_manager_2: :: All errors cleared 2024-03-19 22:57:54.009023 [INFO] evse_manager_1: :: All errors cleared 2024-03-19 22:57:54.030727 [WARN] evse_security:E static std::string evse_security::OpenSSLSupplier::x509_get_responder_url(evse_security::X509Handle*) :: Could not retrieve OCSP Responder URL from certificate 2024-03-19 22:57:54.078883 [INFO] ocpp:OCPP201 :: libocpp: Updating OCSP cache on 0 certificates 2024-03-19 22:57:54.078957 [INFO] ocpp:OCPP201 :: libocpp: Done updating OCSP cache 2024-03-19 22:57:54.197669 [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: 20, reason: Invalid HTTP status., HTTP response code: 401, category: websocketpp.processor, transport error code: 0, Transport error category: system 2024-03-19 22:57:54.197776 [INFO] ocpp:OCPP201 :: Reconnecting in: 2000ms, attempt: 1 2024-03-19 22:57:56.198522 [INFO] ocpp:OCPP201 :: Reconnecting to TLS websocket at uri: wss://host.docker.internal/ws/cp001 with security profile: 3 2024-03-19 22:57:56.201287 [INFO] evse_security:E :: TPM Key: false 2024-03-19 22:57:56.201804 [INFO] evse_security:E :: TPM Key: false 2024-03-19 22:57:56.202785 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms" 2024-03-19 22:57:56.250271 [INFO] ocpp:OCPP201 :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem" 2024-03-19 22:57:56.251505 [INFO] ocpp:OCPP201 :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key" 2024-03-19 22:57:56.260011 [DEBG] ocpp:OCPP201 :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem 2024-03-19 22:57:56.309859 [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: 20, reason: Invalid HTTP status., HTTP response code: 401, category: websocketpp.processor, transport error code: 0, Transport error category: system 2024-03-19 22:57:56.309973 [INFO] ocpp:OCPP201 :: Reconnecting in: 6000ms, attempt: 2 2024-03-19 22:58:02.312647 [INFO] ocpp:OCPP201 :: Reconnecting to TLS websocket at uri: wss://host.docker.internal/ws/cp001 with security profile: 3 2024-03-19 22:58:02.360247 [INFO] evse_security:E :: TPM Key: false 2024-03-19 22:58:02.360947 [INFO] evse_security:E :: TPM Key: false 2024-03-19 22:58:02.362064 [WARN] evse_security:E evse_security::GetKeyPairResult evse_security::EvseSecurity::get_key_pair_internal(evse_security::LeafCertificateType, evse_security::EncodingFormat) :: CSMS leaf requires full bundle, but full bundle not found at path: "/workspace/dist/etc/everest/certs/client/csms" 2024-03-19 22:58:02.363170 [INFO] ocpp:OCPP201 :: Using certificate: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.pem" 2024-03-19 22:58:02.363721 [INFO] ocpp:OCPP201 :: Using key file: "/workspace/dist/etc/everest/certs/client/csms/CSMS_LEAF.key" 2024-03-19 22:58:02.368203 [DEBG] ocpp:OCPP201 :: Loading ca csms bundle to verify server certificate: /workspace/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem 2024-03-19 22:58:02.473193 [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: 20, reason: Invalid HTTP status., HTTP response code: 401, category: websocketpp.processor, transport error code: 0, Transport error category: system 2024-03-19 22:58:02.473319 [INFO] ocpp:OCPP201 :: Reconnecting in: 14000ms, attempt: 3 ```

[sahabulh]

@jhoshiko The warning should not matter here. We are all getting this warning.

Can you please check what's happening on the MaEVe side? Like check logs of MaEVe gateway and manager?

The error at least means that the TLS connection was successful. And there is something wrong with the post TLS validation. That's why it is a HTTP error, not a TLS one. I bet you are getting a "bad organization" error from the gateway. If that's true, you will have to add the organization name "Everest" to the list of allowed organizations in MaEVe Which means we will have to modify the MaEVe code. I have already done that in my fork of MaEVe.

[shankari]

@sahabulh @activeshadow the goal of the MRE is to have a script that showcases the steps needed to enable the functionality that you are interested in. It should run without requiring any changes. If we need to add an EVerest organization to MaEVe, let's do so with a patch, indicating that the change is required. We can then follow up with the MaEVe community to discuss whether the list of orgs should be in the source code or whether it can be pulled out to a config file for easier customization.

[shankari]

@sahabulh if you need an example of how to use a patch, you can see the example in https://github.com/EVerest/everest-demo/pull/19

[jhoshiko]

@sahabulh Here are the logs from the MaEVe manager:

MaEVe manager log

``` 2024-03-20 11:09:24 time=2024-03-20T17:09:24.685Z level=INFO msg=listening name=api addr=[::]:9410 2024-03-20 11:09:24 time=2024-03-20T17:09:24.860Z level=INFO msg=listening name=ocpi addr=[::]:9411 2024-03-20 11:09:45 time=2024-03-20T17:09:45.602Z level=INFO msg="POST /api/v0/cs/cp001" remote_addr=172.21.0.4:59502 status=201 bytes=0 duration=622.751672ms 2024-03-20 11:09:45 time=2024-03-20T17:09:45.746Z level=INFO msg="POST /api/v0/token" remote_addr=172.21.0.4:59506 status=201 bytes=0 duration=7.09604ms 2024-03-20 11:10:24 time=2024-03-20T17:10:24.684Z level=INFO msg="checking for pending charge station certificates changes" 2024-03-20 11:10:24 time=2024-03-20T17:10:24.684Z level=INFO msg="checking for pending charge station settings changes" 2024-03-20 11:10:29 time=2024-03-20T17:10:24.684Z level=INFO msg="sync triggers" duration=91.516758ms sync.trigger.previous="" sync.trigger.count=0 2024-03-20 11:11:05 time=2024-03-20T17:11:05.831Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=7.79831ms 2024-03-20 11:11:09 time=2024-03-20T17:11:09.049Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=3.676958ms 2024-03-20 11:11:16 time=2024-03-20T17:11:16.278Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=3.184878ms 2024-03-20 11:11:24 time=2024-03-20T17:11:24.773Z level=INFO msg="checking for pending charge station certificates changes" 2024-03-20 11:11:24 time=2024-03-20T17:11:24.773Z level=INFO msg="checking for pending charge station settings changes" 2024-03-20 11:11:29 time=2024-03-20T17:11:24.773Z level=INFO msg="sync triggers" duration=31.36846ms sync.trigger.previous="" sync.trigger.count=0 2024-03-20 11:11:32 time=2024-03-20T17:11:32.486Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=5.203985ms 2024-03-20 11:11:34 time=2024-03-20T17:11:34.633Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=4.812048ms 2024-03-20 11:11:35 time=2024-03-20T17:11:35.741Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=5.840972ms 2024-03-20 11:11:39 time=2024-03-20T17:11:39.904Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=3.137003ms 2024-03-20 11:11:48 time=2024-03-20T17:11:48.172Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=2.802441ms 2024-03-20 11:11:50 time=2024-03-20T17:11:50.381Z level=INFO msg="GET /api/v0/cs/cp001/auth" remote_addr=[2001:db8:a::6]:49174 status=200 bytes=53 duration=3.603156ms ```

and here are the logs from the MaEVe gateway:

MaEVe gateway log

``` 2024-03-20 11:09:34 2024/03/20 17:09:34 INFO listening name=ws addr=[::]:9310 2024-03-20 11:09:34 2024/03/20 17:09:34 INFO listening name=wss addr=[::]:9311 2024-03-20 11:09:34 2024/03/20 17:09:34 INFO listening name=status addr=[::]:9312 2024-03-20 11:11:05 2024/03/20 17:11:05 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:05 2024/03/20 17:11:05 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:09 2024/03/20 17:11:09 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:09 2024/03/20 17:11:09 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:09 2024/03/20 17:11:09 ERROR GET /ws/{id} duration=10.097273ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:09 2024/03/20 17:11:09 ERROR GET /ws/{id} duration=4.365253ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:16 2024/03/20 17:11:16 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:16 2024/03/20 17:11:16 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:19 2024/03/20 17:11:19 ERROR GET /ws/{id} duration=3.706381ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:32 2024/03/20 17:11:32 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:32 2024/03/20 17:11:32 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:34 2024/03/20 17:11:34 ERROR GET /ws/{id} duration=6.362641ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:34 2024/03/20 17:11:34 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:34 2024/03/20 17:11:34 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:35 2024/03/20 17:11:35 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:35 2024/03/20 17:11:35 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:39 2024/03/20 17:11:39 ERROR GET /ws/{id} duration=5.665514ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:39 2024/03/20 17:11:39 ERROR GET /ws/{id} duration=6.445951ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:39 2024/03/20 17:11:39 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:39 2024/03/20 17:11:39 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:44 2024/03/20 17:11:44 ERROR GET /ws/{id} duration=4.144878ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:48 2024/03/20 17:11:48 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:48 2024/03/20 17:11:48 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:49 2024/03/20 17:11:49 ERROR GET /ws/{id} duration=3.682693ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} 2024-03-20 11:11:50 2024/03/20 17:11:50 INFO websocket connection received path=/ws/cp001 method=GET 2024-03-20 11:11:50 2024/03/20 17:11:50 INFO processing connection uri=/ws/cp001 2024-03-20 11:11:54 2024/03/20 17:11:54 ERROR GET /ws/{id} duration=4.201889ms http.scheme=wss http.method=GET http.url=/ws/cp001 csId=cp001 ocpp.security_profile=2 auth.organization=[EVerest] auth.common_name=host.docker.internal auth.failure_reason="bad organization" http.status_code=401 http.route=/ws/{id} ```

Looks like you are correct, I am getting a bad organization error.

[sahabulh]

If we need to add an EVerest organization to MaEVe, let's do so with a patch, indicating that the change is required.

@sahabulh if you need an example of how to use a patch, you can see the example in #19

@shankari I know how to use a patch. The reason it worked for me is that I used my own MaEVe fork which had the OrgName added already. I couldn't use the original repo as the load balancer doesn't work for me. Later, just before submitting the PR, I linked the original repo as you suggested doing so. But I forgot to add the changes needed in the original repo.

[sahabulh]

I can submit another PR with the patch file and related command added to the one-liner.

[activeshadow]

I can submit another PR with the patch file and related command added to the one-liner.

@sahabulh I'm working on this right now so don't worry about spending time on it.

[shankari]

Marking this as done since all the changes have been merged