I am currently getting the following error when trying to provision a certificate from the Vault PKI backend:
cannot satisfy request, as TTL would result in notAfter 2029-08-04T12:05:04.236196294Z that is beyond the expiration of the CA certificate at 2029-08-04T11:56:22Z
I noticed in the code that you seem to be able to disable this check in the PKI role with the AllowExpirationPastCA field (https://github.com/hashicorp/vault/blob/master/builtin/logical/pki/cert_util.go#L899):
if caSign != nil &&
notAfter.After(caSign.Certificate.NotAfter) && !data.role.AllowExpirationPastCA {
return nil, errutil.UserError{Err: fmt.Sprintf(
"cannot satisfy request, as TTL would result in notAfter %s that is beyond the expiration of the CA certificate at %s", notAfter.Format(time.RFC3339Nano), caSign.Certificate.NotAfter.Format(time.RFC3339Nano))}
}
but the PKI HTTP API for createe/update role doesn't seem to support this field: https://www.vaultproject.io/api/secret/pki/index.html#create-update-role
How can provision a certificate that lasts longer than its signing CA? My usecase is that I want to provision certificates for as long as possible, which also does not seem straightforward without reading the expiration time of the CA first.
vault --version: Vault v1.0.3 ('85909e3373aa743c34a6a0ab59131f61fd9e8e43')
EDIT: There is an issue open already https://github.com/hashicorp/vault/issues/5834
Related
In ethernet connected system I use harbor registry for docker images in login session it returns x509: certificate relies on legacy Common Name field, use SANs instead error.
How I resolve this certification problem?
You should regenerate your Harbor certificate, the previous maybe
generated by Common Name, use the SAN field to sign the certificate, https://goharbor.io/docs/2.5.0/install-config/configure-https/
I'm trying to issue Vault commands with the cli from my local machine to my remote Vault server but keep getting a bad certificate error.
On the remote Vault server I
created an admin policy as outlined here in admin.hcl
wrote it with vault policy write admin admin.hcl
enabled certificate authentication with vault auth enable cert
associated the admin policy just created with a client admin certificate admin-cert.crt:
vault write auth/cert/certs/user display_name=admin policies=admin certificate=#vault/admin-cert.crt ttl=3600
Then on my local machine I was able to successfully login with this command
vault login -method=cert -ca-cert=CA.crt -client-cert=admin-cert.crt -client-key=client.key.pem name=user
which gave back a token. The output:
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
Key Value
--- -----
token s.Q2NPAIRwhjNRJqvY8LscgSPy
token_accessor bQSI8zGJM4zspnlgvu2XEV1z
token_duration 1h
token_renewable true
token_policies ["admin" "default"]
identity_policies []
policies ["admin" "default"]
token_meta_authority_key_id n/a
token_meta_cert_name user
token_meta_common_name localhost.com
token_meta_serial_number 4285812225508508199151930131872257251014974781
token_meta_subject_key_id n/a
However any subsequent Vault cli commands from my local machine then get back a tls: bad certificate error. I don't think my certs are incorrect as I wouldn't have been able to complete the initial log in in the first place. Rather, it looks like I need to turn off the certificate authentication and use the token for my requests with the Vault cli because I am able to authenticate into the Vault UI with the token.
The -ca-cert argument value used is for the Vault TLS Listener CA certificate, and not the CA that issued the client authentication certificate. Your -client-cert is correct, and your -client-key is probably also correct, but your -ca-cert value should not be the one associated with the authentication engine itself.
The problem was in the configure file.
listener "tcp" {
address = "0.0.0.0:8200"
/*
* Configuration required for mutual TLS
*/
tls_min_version = "tls12"
tls_cert_file = "/home/ubuntu/vault/vault-cert.crt" // path to pem encoded server certificate
tls_key_file = "/home/ubuntu/vault/server.key.pem" // path to pem encoded server private key
tls_require_and_verify_client_cert = "true" // require client certificate from inbound requests
tls_client_ca_file = "/home/ubuntu/vault/client-CA.crt" // path to client CA cert used to validate client certs
The tls_require_and_verify_client_cert needed to be false instead of true. I guess this made requests go through mTLS authentication even after logging in and obtaining the Vault token. However the vault CLI commands other than login don't provide parameters to pass in the certificates needed for mTLS and so the requests failed with the tls: bad certificates error. Turning the mTLS requirement off allows for token authentication of the Vault requests after login.
We have a reporting application which needs JKS file to be created from public certificate and private key associated with the certificate.
For our K8S deployment through Jenkins, we create this application and during this application deployment - pods, svc, ing, certificate also gets created and once our deployment is successful we call another script to use the certificate and private key, create a JKS and copy it to the pod in some location where application can pick it up. This works well but how do we automate this JKS creation and copy it to the pod with every let's encrypt certificate renewal since the certificate is renewed for every 90 days.
Posting an answer from comments.
After some comments, main question was narrowed down to:
"How to renew certificate manually using CertManager?"
Answer itself:
There's a CLI tool for CertManager which is called cmctl.
And it supports manual renewal of certificates by issuing following command:
cmctl renew $CERT_NAME
I have a package that I signed with my own certificate, issued by my own CA.
I signed a nuget package with the certificate.
When I add the root CA in the trust store of the machine, I can verify the signature successfully with nuget, using
nuget verify test.nupkg -Signatures
But, if I remove the root from the trust store, and instead, I add the thumbprint of my certificate as a trusted signers, in nuget, setting allowUntrustedRoot to true, I cannot verify the signature, for some reason.
> nuget trusted-signers
Registered trusted signers:
1. MyCert [author]
Certificate fingerprint(s):
[U] SHA256 - 39544DEE346D61EB2FF5CF4A35EF4B42DE5B4641E1B9AAA098A2A5291F683631
But
> nuget verify test.nupkg -Signatures
Verifying Test
C:\test.nupkg
Signature Hash Algorithm: SHA256
WARNING: NU3027: The signature should be timestamped to enable long-term signature validity after the certificate has expired.
Signature type: Author
Verifying the author primary signature with certificate:
Subject Name: CN=Test Certificate, OU=Test, C=BE
SHA1 hash: 679B1E503720C69D981B9CC4F0199D5D8593375A
SHA256 hash: 39544DEE346D61EB2FF5CF4A35EF4B42DE5B4641E1B9AAA098A2A5291F683631
Issued by: CN=Test Root, OU=Test, O=Test, C=BE
Valid from: 10/31/2019 10:29:54 AM to 9/24/2023 11:37:39 AM
NU3018: The author primary signature found a chain building issue: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
WARNING: NU3018: The author primary signature found a chain building issue: The revocation function was unable to check revocation because the revocation server could not be reached. For more information, visit https://aka.ms/certificateRevocationMode.
WARNING: NU3018: The author primary signature found a chain building issue: The revocation function was unable to check revocation for the certificate.
Finished with 1 errors and 3 warnings.
Package signature validation failed.
What's the point of adding a trusted signer and setting allowUntrustedRoot to true if the signature is not verify. I mean, it's apparently enough to add the root certificate to the trust store for the signature to be verified, without doing anything with the configuration.
I would like, if possible, to be able to not import the root CA in the trust store, and only use the configuration of Nuget to verify successfully the signature.
Thanks.
Our belief is that if you tried to use that package in a project with those trust policy settings appropriately in nuget.configs, restore will succeed.
Please confirm that.
Next, nuget verify has a -config switch -- please try passing in the path to your nuget.config.
If the first test works, and the second test doesn't, nuget may have a bug in the verify command. If so, please file an issue at https://github.com/nuget/home/issues/
-Rob Relyea (NuGet Client Team)
I have an encrypted application secret.
In my ApplicationManifest I have specified the corresponding certificate to decrypt the secret:
<Certificates>
<SecretsCertificate Name="MyCert" X509FindValue="1..." X509FindValueSecondary="2..." />
</Certificates>
My secret is actually encrypted with the 2... certificate, which I specified in X509FindValueSecondary. I thought that when it does not find the certificate of X509FindValue, in my case 1..., it will fall back to looking for the certificate in X509FindValueSecondary. This is what I thought "Secondary" means.
However, my application does not start:
Failed to configure certificate permissions. Error FABRIC_E_CERTIFICATE_NOT_FOUND.
What is the difference between X509FindValue and X509FindValueSecondary?
SecretsCertificate uses the same formatting for other certificate options like
ServerCertificate, ClientCertificate and so on.
What is the difference between X509FindValue and X509FindValueSecondary?
Assuming they all work the same way, the idea of X509FindValueSecondary for ServerCertificate is to be used as a rollover approach, that means:
Load the first certificated, if it is valid, use it
if first certificate expires, try load the second
In both cases, the certificate must exist, because it requires to validate the expiration dates, if you plan to have just one, you should remove the secondary.