-
Notifications
You must be signed in to change notification settings - Fork 236
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
Puppetserver CA API race-condition(?) #2851
Puppetserver CA API race-condition(?) #2851
Comments
Example when executed on the CA server itself:
The system in question has had a certificate previously but no longer does. Neither a certificate or a certificate request file exists for the system on the CA. For other non-existing nodes it correctly returns One workaround seems to be having the node connect to the CA and hence generating a new CSR file. However, revoking As mentioned earlier this only happens sometimes and after it has started to happen it is persistent for that particular subject DN. The CA is also much slower to process CSRs -> Cert (as also mentioned in linked issue). |
Thanks for your report. The issue is a simple logic problem that I will resolve shortly. |
The inventory is managed in several ways in the CA, including an inventory file, which records certificates, expiration periods and serial numbers. In the case where we want to get the actual certificate status, we don't want to use the inventory file. The liberator `exists` method was checking in both the filesystem and the inventory file for the certificate in question for a `GET` request. This alters that behavior to only check the file system under those circumstances. A test is added to demonstrate the behavior. Resolves puppetlabs#2851
The inventory is managed in several ways in the CA, including an inventory file, which records certificates, expiration periods and serial numbers. In the case where we want to get the actual certificate status, we don't want to use the inventory file. The liberator `exists` method was checking in both the filesystem and the inventory file for the certificate in question for a `GET` request. This alters that behavior to only check the file system under those circumstances. A test is added to demonstrate the behavior. Resolves puppetlabs#2851
@jonathannewman @justinstoller Hi, when will there be a release which includes this fix? Thanks. |
Describe the Bug
Puppetserver CA API gets into a race-condition sometimes when the Certificate Status endpoint is used to first revoke and afterwards clean the certificate. When this occurs puppetserver will start throwing
ERROR [p.r.core] Internal Server Error: java.io.FileNotFoundException: /path/to/cert.pem (No such file or directory)
when attempts to revoke/clean said certificate occurs.We have not seen this bug in 7.13.0 and earlier versions. First time it occurred was after updating to 8.4.0.
Expected Behavior
Certificate is successfully revoked and cleaned and can be re-used.
Steps to Reproduce
Steps to reproduce the behavior:
ERROR [p.r.core] Internal Server Error: java.io.FileNotFoundException: /path/to/cert.pem (No such file or directory)
As stated earlier. This does not always happen.
Environment
-- puppet.conf - autosign set to run a script
-- auth.conf - allow a specific certificate to use endpoint - /puppet-ca/v1/certificate_status
-- puppetserver.conf - ca-ttl set: 5y
-- puppetserver.conf - allow-auto-renewal: true
-- puppetserver.conf - auto-renewal-cert-ttl: 5y
Additional Context
It seems to help to have the node reach out to the CA and have a new certificate request recreated and then use API to sign it. Afterwards it works again as expected.
puppetlabs/puppetserver-ca-cli#120 migh be related.
Example logs:
The text was updated successfully, but these errors were encountered: