open-ocpp icon indicating copy to clipboard operation
open-ocpp copied to clipboard

Certificate validation fails

Open Rikie1979 opened this issue 10 months ago • 3 comments

Hello all,

I have a question about the Iso15118 certificate handling. When we receive a signed v2g SECC certificate, the Iso15118Manager.cpp calls the 'verify' function on the received certificate (Line 289). But this calls fails probably since there is no root certificate in the chain (also not required as far as I know). Is this check really necessary?

Kind regards,

Rik van Ark

Rikie1979 avatar Feb 11 '25 12:02 Rikie1979

Hi,

The requirement in the whitepaper says:

5. The Central System sends the certificate it has acquired from the CA to the Charge Point, using the CertificateSigned.req
message.
6. The Charge Point verifies the Signed Certificate and if valid, it installs it as its ISO 15118 Charging Point certificate. If the
certificate is invalid the Charge Point must reject the CertificateSigned.req message by sending a CertificateSigned.conf
message with status Rejected

So the charge point has to verify the contents of the certificate. What is unclear here is : what must the chargepoint verify in the certificate?

If we want to verify only if the format of the certificat is vali (i.e. valid PEM), we can skip the verify. If we also want to verify the certificate's signature, then the CA certificate which has signed the certificate must also be provided to the charge point.

In the description of the CertificateSigned.req message, the field is named certificateChain and has the following description:

Required. The signed PEM encoded X.509 certificate. This can
also contain the necessary sub CA certificates. In that case, the
order of the bundle should follow the certificate chain, starting
from the leaf certificate.

It seems that it is expected to have a chain of certificate, including sub-CA if needed, along with the certificate itself. Hence the implementation in the open-ocpp library.

I didn't try this implementation with real CSMS and real EV cars so I may have missed something.

Maybe we can add a configuration switch to disable the certificate chain verification so that both behavior can be accepted?

c-jimenez avatar Feb 11 '25 12:02 c-jimenez

Hi, First, thank you very much for your fast reply! In my my scenario I receive a leaf certificate, subCA2 and subCA1 certificates. But the verify function fails. I was asuming this is because of the missing root (self signed) certificate. Since I read somewhere OpenSSL uses that to determine the end of the chain.

So I don't mind the check as long as it works 🙂

But it sounds good to me to use a parameter to enable/disable the option.

Regards,

Rik


Van: c-jimenez @.> Verzonden: dinsdag 11 februari 2025 13:58 Aan: c-jimenez/open-ocpp @.> CC: Rikie1979 @.>; Author @.> Onderwerp: Re: [c-jimenez/open-ocpp] Certificate validation fails (Issue #230)

Hi,

The requirement in the whitepaper says:

  1. The Central System sends the certificate it has acquired from the CA to the Charge Point, using the CertificateSigned.req message.
  2. The Charge Point verifies the Signed Certificate and if valid, it installs it as its ISO 15118 Charging Point certificate. If the certificate is invalid the Charge Point must reject the CertificateSigned.req message by sending a CertificateSigned.conf message with status Rejected

So the charge point has to verify the contents of the certificate. What is unclear here is : what must the chargepoint verify in the certificate?

If we want to verify only if the format of the certificat is vali (i.e. valid PEM), we can skip the verify. If we also want to verify the certificate's signature, then the CA certificate which has signed the certificate must also be provided to the charge point.

In the description of the CertificateSigned.req message, the field is named certificateChain and has the following description:

Required. The signed PEM encoded X.509 certificate. This can also contain the necessary sub CA certificates. In that case, the order of the bundle should follow the certificate chain, starting from the leaf certificate.

It seems that it is expected to have a chain of certificate, including sub-CA if needed, along with the certificate itself. Hence the implementation in the open-ocpp library.

I didn't try this implementation with real CSMS and real EV cars so I may have missed something.

Maybe we can add a configuration switch to disable the certificate chain verification so that both behavior can be accepted?

— Reply to this email directly, view it on GitHubhttps://github.com/c-jimenez/open-ocpp/issues/230#issuecomment-2650746875, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BPMLRYZPOIGHF3WGB4HM3J32PHXVTAVCNFSM6AAAAABW45R4J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJQG42DMOBXGU. You are receiving this because you authored the thread.

Rikie1979 avatar Feb 11 '25 13:02 Rikie1979

@c-jimenez I have also seen situations where the root certificate is not part of the received chain.

About verification, its a good question. Given the limitation of an absent root certificate, I say the following can at least be verified:

  • Valid PEM
  • Not expired
  • That the received certificate matches a csr that was transmitted from the charge station (this is up to the user application that generated the csr)

Full validation of the chain is not possible when the root is not there. I would be fine with a configuration option for that like you propose.

Habbus avatar Apr 10 '25 14:04 Habbus