-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Certificate validation fails #230
Comments
Hi, The requirement in the whitepaper says:
So the charge point has to verify the contents of 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. In the description of the
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? |
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:
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?
—
Reply to this email directly, view it on GitHub<#230 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BPMLRYZPOIGHF3WGB4HM3J32PHXVTAVCNFSM6AAAAABW45R4J2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJQG42DMOBXGU>.
You are receiving this because you authored the thread.
|
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
The text was updated successfully, but these errors were encountered: