feat: pull mo-trust-anchor at bootup rather than from file #4
Conversation
There was a problem hiding this comment.
I wonder if it makes sense for us to create a MoRootCertificateRetrievalService with the following implementations:
- OpcpMoRootCertificateRetrievalService
- FileMoRootCertificateRetrievalService
The serve command can then either use the file based option if the --mo-trust-anchor-pem-file flag is provided or the RCP option if we specify --mo-rcp-opcp-url and --mo-rcp-opcp-token flags are provided?
The service would be passed down to the handlers that actually need to certificates so there is the option for dynamic updates etc.
| - "--cso-opcp-token" | ||
| - "${CSO_OPCP_TOKEN}" | ||
| - "--mo-opcp-token" | ||
| - "${MO_OPCP_TOKEN}" | ||
| - "--storage-engine" | ||
| - "${STORAGE_ENGINE:-firestore}" | ||
| - "--mo-root-certificate-pool" | ||
| - "https://open.plugncharge-test.hubject.com/mo/cacerts/ISO15118-2" |
There was a problem hiding this comment.
I get 403 RBAC: access denied on this URL
|
@subnova I added the changes proposed. It does not pass the service through the handler though. That requires a few more changes, but it is an incremental improvement that we can iterate over. Any thoughts? |
…t through cli flags
…t through cli flags
subnova
force-pushed
the
pull-mo-trust-anchor
branch
from
89b407b
to
a42ca0b
Compare
Allow manager to pull mo-trust-anchor at boot-up rather than from file in file system