Hi,
I have a question below.
Is it possible to install Let's Encrypt certificate in a charging station?
Because, I should install a certificate not only a server but also a charging station in order to communicate with wss bi-directional TLS.
Thanks.
Hi @engineer,
What software environment runs on the charging station? How do you administer it?
And, what network identifier or name do you use to connect to it?
It sounds like you may be using the websocket version of OCPP and you want a client certificate for OCPP security profile 3. Let's Encrypt certificates can I believe be used for client authentication but this will depending on the charging station management system as it may prefer to issue it's own client certificate (in fact I'd assume this was the normal case).
https://www.wevo.energy/white-papers/open-charge-point-protocol-ocpp-security-explained/\
[As an off-topic aside, if you are operating a public charging network or participating in one, please consider sharing your data to https://openchargemap.org - we accept OCPI data feeds or locations can be manually submitted.]
What do you mean by bi-directional TLS? Do you mean the command and control station need to connect to charging stating which hosts a TLS server? Or you actually need a client certificate in charging station to authenticate with the server?
Anyway in both cases, every charging server need to be assigned a hostname under a valid domain name, and you have to have a way to automatically renew the certificate every 2 months.
I believe the more important problem is how the charging station renews the certificate every two months
I'd have to look into it again but last time I looked there was a whole set of standards (similar idea to ACME) for certificate acquisition, although I was looking at it more to do with vehicle certs (where the vehicle OEM and the network are both CAs).
Either way, as it pertains to ACME a charging station would not be accessible over public http for http validation to work, and it's unlikely they'd store dns credentials on the device for dns validation, so it's most likely it would download it's own certificate from the management system (or have it pushed).
Thanks for answering my question.
A server and a client both have to have a certificate.
And when they communicate, both side has to establish connection by sending Public Key each other.
Thanks for answering my question.
You are right.
I'm handling OCPP Server with a charging station as well to apply OCPP security profile 3.
Great, are you implementing the OCPP server/management system yourself or are you using a 3rd party product?
If 3rd party I'd expect they already have something, if developing yourself:
A charging station is just a computer and the "trust" between the two computers (your charging station and the management system) is presumably completely under your control. This means you can run your own certificate authority software (like smallstep step ca or any others) to issue certificates, or use a public CA like Let's Encrypt. The difference with a private CA you run yourself is that you need to distribute the root certificate to the trust store of the client machine (the charging station) so that it trusts communication with the server). You also need to protect access to the private key of the root certificate as this hold the keys to all of your certificate trust.
You can issue client certificates from your own CA and push them to the charging station on first joining the network and periodically to keep them up to date. The management system would trust the same root certificates from the same CA, so it would trust the client certificates presented by the charging stations. You should refer to the OCPP standard to see if there are established way to achieve this in the protocol.
If you want to use public CA certificates I'd suggest a centrally managed certificate renewal system which then pushes the client certificates to the management system (or to the management system can pull from). For instance you could allocate certificates for each charging point and push them to a key vault such as Hashicorp Vault or Azure Key Vault, then allow the management system to pull those on demand and send them to the charging stations. The software I develop (https://certifytheweb.com) can do this certificate renewal/storage, but there are many other tools you could also use to achieve the same thing. This is a just a suggested way of doing things.
The core of using certificates is that the CA's root certificate (public key generated from a secret private key they hold) is distributed to trust stores (CA bundles etc) on client machines, this makes all certificates issued by that CA trusted on machine that trust that root certificate. As part of this you also need to have a plan for updating the CA root certificates if they expire or need to be urgently replaced (pushing updates to the clients, or clients polling for changes). If the CA is also issuing the client certificates then they are naturally trusted by management system if it also trusts the same root certificate(s). How "trust" works exactly depends on the operating systems and software being used.
If you are considering certificates and PKI, you should also look into the standards for EV communication (client certificates for vehicles) as there are extensive standards being developed in this field (ISO 15118, so EVs can plug in and charge by presenting their own client certificates, without any other app/login/authentication). You will see there are many organisations trying to establish software solutions in this field: https://www.digicert.com/content/dam/digicert/pdfs/whitepaper/ev-charging-whitepaper-practical-considerations-for-implementation-and-scaling.pdf
Note: I'm not a charging stations communications expert, I just happen to have been involved in charging station mapping for 12 years or so.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.