Vault-generated private keys throw FailedToConstructPrivateKey errors
Opened this issue · 2 comments
Hello-
I've deployed linkerd as well as a couple sample applications with linkerd-tcp containers. We've successfully applied cfssl and openssl certificates and keys, but are having trouble with keys generated with Vault. Our pk8-encoded key will throw the error "WrongNumberOfKeysInPrivateKeyFile" and our regular .key file will throw "FailedToConstructPrivateKey" errors. There does not appear to be any errors with the certificates on the client side. We have similar vault-generated certs that work with our main linkerd service mesh.
client configuration:
routers:
...
client:
kind: io.l5d.static
configs:
- prefix: /svc/server
connectTimeoutMs: 400
tls:
dnsName: "server.default.svc.cluster.local"
trustCerts:
- /io.buoyant/linkerd/certs/tls.chain
server configuration:
routers:
...
servers:
- ip: 0.0.0.0
port: 7474
dstName: /$/inet/127.1/80
tls:
defaultIdentity:
privateKey: /io.buoyant/linkerd/certs/tls.key
certs:
- /io.buoyant/linkerd/certs/tls.crt
Is there any reason that this may be happening to Vault keys and not other private keys?
My hunch is that the keys are RSA keys and they either are missing the Chinese Remainder Theorem (CRT) parameters or they have the CRT parameters but parameter p
< parameter q
. If it is the latter then the fix for briansmith/ring#220 will fix this after we upgrade the version of ring being used.
@briansmith I believe you're correct; these are RSA keys, and looking at Vault's keybase/go-crypto/rsa
dependency shows the same issue as with the crypto/rsa
package that has already been called out in briansmith/ring#220 as possible sources of such keys (i.e. no sorting of the p
/q
parameters).
It does seem like the p
and q
parameters are at least present, so I suspect that upgrading ring
will fix this issue.