Bug 1641119
| Summary: | CC: CA/OCSP startup fail on SystemCertsVerification if enableOCSP is true | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Christina Fu <cfu> | |
| Component: | pki-core | Assignee: | Jack Magne <jmagne> | |
| Status: | CLOSED ERRATA | QA Contact: | Asha Akkiangady <aakkiang> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | high | |||
| Version: | 7.6 | CC: | akahat, cpelland, edewata, jmagne, mharmsen | |
| Target Milestone: | rc | Keywords: | TestCaseProvided, ZStream | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | pki-core-10.5.16-2.el7 | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: This issue arises when restarting either a CA or OCSP subsystem that has been configured for OCSP checking.
Consequence: When such a server is restarted the selftests designed to test the validity of the subsystem certs in a given subystem fail due to the presence of OCSP checking.
Fix:
The fix is to modify the the selftests for CA and OCSP only to perform a simpler set of cert validity tests, which do not cause problems.
This new behavior now takes place by default. The original behavior can be forced with the following CS.cfg value:
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true
With this setting the original behavior will take place. This would only be desired in cases where OCSP checking has not been configured, and the full cert validity tests are desired.
Result:
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1657922 (view as bug list) | Environment: | ||
| Last Closed: | 2019-08-06 13:07:19 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1657922 | |||
|
Description
Christina Fu
2018-10-19 16:44:41 UTC
an update from discussion with Gossamer this morning: They believe that we could redefine selftests so that they don't have to do revocation checking. We could special-case CA/OCSP so they do just expiration checks and/or some other easier-to-check "vital signs" of a CA or OCSP. This should minimize the work required for us. The checking for this has been in master:
commit c7b8771119f2e055bdca322afd7986cb653ccbd3
Author: jmagne <jmagne>
Date: Thu Nov 8 17:07:40 2018 -0800
Resolve: Bug 1641119 - CC: CA/OCSP startup fail on SystemCertsVerification if enableOCSP is true. (#87)
The approach taken by this patch is quite simple. The SystemCertsVerification self test has been modified to
optionally act differently when verifying the system certs of both ca and ocsp instances.
Previously, the test would do a full cert verification , which results in an ocsp check being done at the nss level, if ocsp has been enabled in the server.xml. The past result was to have the server hang on startup , due to the fact that an ocsp check of a given cert would loop back to the ca or ocsp server itself to do the work. In the case of the self test /startup scenario, the server will not be sufficiently ready to field such a request, thus resulting in a hang situation.
This fix modifies the cert checks for ca and ocsp to ONLY do a validity test for each cert.
The code has created an optional parameter than can force our of this behaviour if the admin absolutely wants to:
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify= true
IF, the admin wants the test to behave as it did before. This may be the case where we know ocsp is not configured for the ca or ocsp itself.
The value, is false by default and is false if the line is not present.
The simple validity test is all that gets done at this point but could be modified to do more in the future.
We already have a validity test for just the CA singing and OCSP signing certs. I felt it was cleaner to just leave those in place unchanged, safely leaving the original wiring in place.
Branch checkin:
commit 3eab287365d83a167fff7ec1287bd70647e93757 (HEAD -> DOGTAG_10_5_BRANCH, origin/DOGTAG_10_5_BRANCH)
Author: jmagne <jmagne>
Date: Thu Nov 8 17:07:40 2018 -0800
Resolve: Bug 1641119 - CC: CA/OCSP startup fail on SystemCertsVerification if enableOCSP is true. (#87)
The approach taken by this patch is quite simple. The SystemCertsVerification self test has been modified to
optionally act differently when verifying the system certs of both ca and ocsp instances.
Previously, the test would do a full cert verification , which results in an ocsp check being done at the nss level, if ocsp has been enabled in the server.xml. The past result was to have the server hang on startup , due to the fact that an ocsp check of a given cert would loop back to the ca or ocsp server itself to do the work. In the case of the self test /startup scenario, the server will not be sufficiently ready to field such a request, thus resulting in a hang situation.
This fix modifies the cert checks for ca and ocsp to ONLY do a validity test for each cert.
The code has created an optional parameter than can force our of this behaviour if the admin absolutely wants to:
selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify= true
IF, the admin wants the test to behave as it did before. This may be the case where we know ocsp is not configured for the ca or ocsp itself.
The value, is false by default and is false if the line is not present.
Patch built and tested on f27 vm.
I tested this bugzilla on 10.5.16-2.el7 I tried the steps which are mentioned in comment #6. - Installation of standalone CA, KRA and OCSP, after restart observed logs. - Setup selftests.plugin.SystemCertsVerification.FullCAandOCSPVerify=true in subsystem's CS.cfg file and restart the subsystem. - I could see that there are different logs. Which is working as expected. Verifying this bugzilla. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2228 |