Hi folks,
I’m setting up OIDC authentication to my test-lab Vault instance, using Authelia as the OIDC provider. The Authelia instance is presenting a TLS certificate from a private root CA, so I need to let Vault know to trust that root. Ordinarily, I’d just add it to the system set (since I’m using it elsewhere as well), but Vault is running in Docker here so it has its own set of trusted roots inside the container.
My initial attempt to set up OIDC was this:
vault write auth/oidc/config oidc_discovery_url="https://idm.private.lan" oidc_client_id="magic_client_ID_goes_here" oidc_client_secret="magic_client_secret_goes_here" default_role="user"
Logically, that failed with a complaint about the oidc_discovery_url cert being issued from an unknown issuer. So I copied the root cert in PEM format into the container and tried this, referencing the Vault docs on the OIDC endpoint:
vault write auth/oidc/config oidc_discovery_ca_pem="/vault/config/private_root.crt" oidc_discovery_url="https://idm.private.lan" oidc_client_id="magic_client_ID_goes_here" oidc_client_secret="magic_client_secret_goes_here" default_role="user"
However, that generates this error in the logs:
2025-05-19T20:29:10.636Z [ERROR] auth.oidc.auth_oidc_0d31bd3c: error checking oidc discovery URL: error="error creating provider: NewConfig: invalid provider config: Config.Validate: invalid CA certificate"
The only way I could figure out to get this to work was to hand-edit /etc/ssl/certs/ca-certificates.crt in the container and paste the root-cert PEM to the end of it. After that, I used the first command (without the oidc_discovery_ca_pem argument) and it worked perfectly. Obviously that’s not repeatable, though: as soon as I upgrade or replace the Vault container, it’ll break.
Is there some other way I’m supposed to get this to work?
For this use case, I think you are into container specific management processes vs having Vault manage this since you are trusting an external CA. Options might be a custom image that pulls the cert in when created, or updating the process you use to start the container to get the cert and update the trusted certs.
That’s a pity, but it’s where I was worried this would land anyway — it’s quite clumsy and adds overhead to the container-upgrade process. Not impossible, but it is annoying that specifying oidc_discovery_ca_pem doesn’t seem to fix this when the docs seem to indicate it should.
Hmm I had understood in differently, but re-reading your interpretation has me wondering now. Let me ask around.
Answer I got back
This is for the /.well-known/openid-configuration endpoint and it simply configures the HTTP client with info about what certificate authority to expect for that HTTPS connection.You should not need to trust it at the OS level if you configure it here.
So when you put the cert i the OIDC config it gives you an error, but when you put /etc/ssl/certs it works 
When you write the cert as part of the auth method config, do you see the cert as expected when you read back the configuration from Vault?
The error I posted there is fatal: the client won’t let me write the configuration with the oidc_discovery_ca_pem option and that certificate — once I added it to /etc/ssl/certs, I then ran the command without that argument. I’ll pull up the container and experiment, though: I’m curious to know whether, once the cert is added to /etc/ssl/certs, I can then specify it on the command-line and write it into the OIDC config. (Not sure that makes any difference, but it would be good to know.)
I think you need to @ the oidc_ca_cert parameter to read the file so something like
oidc_discovery_ca_pem=@/vault/config/private_root.crt
The Kubernetes OIDC doc shows an example of that