SECC requiring the contract leaf key

[sahabulh]

SECC requiring the contract leaf key

[shalinnijel2]

Correct - in this case the simulator is trying to simulate what Hubject would do - fetch the contract, related chain etc for the EV and base64 encode the CertificateInstallationRes which the CS would then forward to the EV. If you are using the evcc simulator and wish to skip this step (which would be the case if the evcc has the required certificates already) , you could change the return value in is_cert_install_needed() to False

[sahabulh]

Thank you for your response. Sorry, I didn't understand your explanation completely. I understand that I can turn off the initial certificate installation. But in case I want it, how should it work? Isn't it like this:
The EVCC creates the certificate installation request, signs it using it's OEM provisional private key, then sends it to the SECC. The SECC signs it using it's own key and then forwards it to the MOSubCA2. The MOSubCA2 then processes the message, creates the contract certificate along with the contract private key, encrypts it using the EV's OEM public key, signs it using it's own private key, then sends it to the SECC. The SECC forwards it to the EV. The EV can decrypt it using it's oem private key and get the contract cert.
If it is like this, then there is no need for the SECC to hold the contract key of the EVCC. Sorry, I just want to know how this work and checking if there is something I am misunderstanding.

[shalinnijel2]

Sure - the SECC doesn't sign the installation request coming from the EV as there is no need for the backend or Hubject to be able to verify the SECC that the request originated from. All they need to verify is the OEM - which is where - like you mentioned - signing the request with the OEM private key helps. The contract generated would be present in Hubject's contract certificate pool which could be fetched with : https://hubject.stoplight.io/docs/open-plugncharge/9fabe1661696f-get-signed-contract-data
And would have been placed in the pool beforehand by the eMobility service provider when the EV owner/manager signed up for a contract:
https://hubject.stoplight.io/docs/open-plugncharge/4349a542634c0-generate-signed-contract-data

In this repo - the env variable USE_CPO_BACKEND is used to indicate if the required backend is available to do the necessary calls to fetch the CertificateInstallationRes. If set to false - then the assumption is that everything required to build the response (MO Contract, SubCA1, SubCA2 certs) is locally available and simulates the Hubject response - which is to generate the certificateInstallationRes in base64 encoded form.

Please forgive the self promotion ;) - but I think this is an excellent diagram describing all the players involved:
https://youtu.be/ztwnmyya-nQ?t=2991

[tropxy]

The project is doing what is supposed to and I believe the explanation from Shalin was clear. If not the case, @sahabulh please reopen the issue and let us know what is not clear yet.