OIDCDiscoveryURL and https

I am trying to set up auto_config for my consul clients. It is moving along, but I keep running into problems that are making me stumped for what to do next. But slow and steady wins the race!

So, right now, I am struggling with logging in using my initial jwt, which it does… Sort of? I am soon met with a wall of log messages like these:

2023-01-28T17:34:48.034Z [ERROR] agent: yamux: Failed to read header: remote error: tls: bad certificate
2023-01-28T17:34:48.034Z [WARN]  agent.client: Retrying RPC to server: method=ConnectCA.Roots server=10.0.0.6:18300 error="rpc error making call: EOF"
2023-01-28T17:34:48.034Z [WARN]  agent.client: Retrying RPC to server: method=Catalog.NodeServiceList server=10.0.0.6:18300 error="rpc error making call: EOF"

and, moving instead to the server, the other part of this communication seems to be this, as far as I can tell:

Jan 28 17:36:01 consul-server consul[1311]: 2023-01-28T17:36:01.702Z [ERROR] agent.server.rpc: failed to read byte: conn=from=10.0.0.3:53207 error="tls: failed to verify client certificate: x509: a root or intermediate certificate is not authorized to sign for this name: DNS name \"localhost\" is not permitted by any constraint"
Jan 28 17:36:02 consul-server consul[1311]: 2023-01-28T17:36:02.841Z [ERROR] agent.server.rpc: failed to read byte: conn=from=10.0.0.3:56405 error="tls: failed to verify client certificate: x509: a root or intermediate certificate is not authorized to sign for this name: DNS name \"localhost\" is not permitted by any constraint"
Jan 28 17:36:03 consul-server consul[1311]: 2023-01-28T17:36:03.782Z [ERROR] agent.server.rpc: failed to read byte: conn=from=10.0.0.3:49187 error="tls: failed to verify client certificate: x509: a root or intermediate certificate is not authorized to sign for this name: DNS name \"localhost\" is not permitted by any constraint"

I have read that the agent always asks for the localhost, 127.0.0.1, and ::1 SANs in the configuration, and I assume this would be related to that, but I can make no sense from the audit logs in vault what is going on. Consul clearly doesn’t hammer the vault server in the same way the client hammers the consul servers with the above messages, which seems a good thing, but makes it harder for me to understand what is happening.

  • Which certificate needs to be able to provide the localhost domain, if that is indeed the problem?
  • If this is indeed the problem, since consul from what I’ve understood of how setting this up, that path is managed by consul on it’s own, is it the connect_root that needs to be configured differently to allow it to make it’s own certificate perform as expected?