Skip to content
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

Error starting agent: AutoEncrypt failed: unknown private key type requested: on autoencrypt enabled client #6391

Closed
nagraskal opened this issue Aug 24, 2019 · 7 comments · Fixed by #6392
Labels
theme/tls Using TLS (Transport Layer Security) or mTLS (mutual TLS) to secure communication type/bug Feature does not function as expected

Comments

@nagraskal
Copy link

When enabling autoencrypt on 1.6.0rc1 client with
"auto_encrypt": {
"tls": true
}
I get
Error starting agent: AutoEncrypt failed: unknown private key type requested: (without a type...)
Same configuration works on 1.5.3.
seems like the client agent never tries to reach out to a consul server node at all.
There is no option mentioned in the documentation to set the key type.

@hanshasselberg
Copy link
Member

Thanks for reporting @nagraskal! This is clearly a bug and I will look into it!

@hanshasselberg hanshasselberg added type/bug Feature does not function as expected theme/tls Using TLS (Transport Layer Security) or mTLS (mutual TLS) to secure communication labels Aug 26, 2019
@nagraskal
Copy link
Author

great, thanks!

@luanbon
Copy link

luanbon commented Aug 26, 2019

I am deploy a new server cluster with 1.6.0 and i am facing the same problem..

@ericbrumfield
Copy link

I'm getting the same error with a new agent running in client mode using consul v1.6.0 on rhel 8. The rest of our test cluster has other consul agents running in client and server mode that are working in windows server with a similar config and those are all running consul v1.5.3.

Downgraded consul in the rhel 8 box back to 1.5.3 for consistency and this error when away on the client/agent side for me.

@hanshasselberg
Copy link
Member

Yes it is a known problem and will be fixed in the next release. Thanks for reporting!

@tradel
Copy link
Contributor

tradel commented Aug 27, 2019

Hi @nagraskal @ericbrumfield. Until we cut the next release including the fix in #6392, there is an undocumented workaround you can try. Just add the following to the configuration on the client:

"connect": {
  "enabled": true, 
  "ca_config": {
    "private_key_type": "ec",
    "private_key_bits": 256
  }
}

I have tested this with the 1.6.0 GA release.

@nagraskal
Copy link
Author

thank you @tradel for the workaround, but isn't the connect stanza meant to be in the server config and not the client config?

I use vault as certificate backend, and if I add this stanza to the client configuration, the client connects, but there are no certificates generated in vault - I am not sure what happens here - does consul use the internal ca?

and btw., if consul generates the ca and intermediate ca pki in vault, the leaf-cert role is configured to generate rsa keys with 2048 bits, so not matching the configuration options.

I did try with the rc.

thanks!

jinnko added a commit to ixydo/terraform-aws-consul that referenced this issue Sep 5, 2019
There's a known issue[1] in v1.6.0 that prevents consul clients from
contacting the servers when they're configured to auto-join.  This
workaround[2] gets things working.

1: hashicorp/consul#6391
2: hashicorp/consul#6391 (comment)
jinnko added a commit to ixydo/terraform-aws-consul that referenced this issue Sep 5, 2019
There's a known issue[1] in v1.6.0 that prevents consul clients from
contacting the servers when they're configured to auto-join.  This
workaround[2] gets things working.

1: hashicorp/consul#6391
2: hashicorp/consul#6391 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
theme/tls Using TLS (Transport Layer Security) or mTLS (mutual TLS) to secure communication type/bug Feature does not function as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants