Bug 1875563
Summary: | Add KRA Transport and Storage Certificates profiles, audit for IPA | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Asha Akkiangady <aakkiang> | |
Component: | pki-core | Assignee: | Christina Fu <cfu> | |
Status: | CLOSED ERRATA | QA Contact: | PKI QE <bugzilla-pkiqe> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 8.3 | CC: | abokovoy, alee, cfu, cpinjani, edewata, extras-qa, fdc, frenaud, ftweedal, ipa-maint, jhrozek, mharmsen, mhjacks, mkosek, pvoborni, rcritten, ssorce, twoerner, wdh | |
Target Milestone: | rc | Keywords: | TestCaseProvided | |
Target Release: | 8.0 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | pki-core-10.6-8040020201214190754.d4d99205 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | 1869605 | |||
: | 1883639 (view as bug list) | Environment: | ||
Last Closed: | 2021-05-18 15:25:15 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: | 1869605 | |||
Bug Blocks: | 1872603, 1872604, 1883639 | |||
Deadline: | 2020-12-08 |
Description
Asha Akkiangady
2020-09-03 19:00:48 UTC
*** Bug 1875565 has been marked as a duplicate of this bug. *** Hi, I'm about to get started on this bug. I just want to confirm if my understanding is correct on what's expected from RHCS: - I'll create the two profiles (in files), with proper CS.cfg changes - I'll create necessary upgrade scripts I'd do minimum tests within CS itself just to make sure the profiles are correct. Christina, Sounds good to me. Thank you! commit e6531d9bf0d7a4cbe346dc610c19ad3f41b2f18a (HEAD -> master, origin/master, origin/HEAD) Author: Christina Fu <cfu> Date: Thu Sep 10 14:19:25 2020 -0700 Bug1875563-Add KRA Transport and Storage Certificates profiles for IPA This patch adds two profiles for IPA, namely caIPAKraTransportCert caIPAKraStorageCert Both are consistent with with the existing profile caIPAserviceCert where visible=false auth.instance_id=raCertAuth raCertAuth is an instance of AgentCertAuth with agentGroup=Registration Manager Agents Upgrade scripts are provided to handle upgrades as well. fixes https://bugzilla.redhat.com/show_bug.cgi?id=1875563 Test procedure for RHCS QE: There are two things to test. One being that the upgrade scripts work - this could be achieved by upgrading the rpms, and restart a previously installed instance, then observe that the two caIPAKra* profiles show up under /var/lib/pki/<instance>/ca/profiles/ca/ The other being that the profiles actually work; Here is the minimum test I did on the RHCS side (feel free to improve upon or automate it): I edited both /var/lib/pki/<instance>/ca/profiles/ca/caIPAKraStorageCert.cfg and /var/lib/pki/<instance>/ca/profiles/ca/caIPAKraTransportCert.cfg so that visible=true restart the CA (QE, for this following step, I suggest you create a role user that belongs to Registration Manager Agents and load the user's cert to the browser to test) I took a short cut and simply changed the auths.instance.raCertAuth.agentGroup= value in CS.cfg to Certificate Manager Agents and just use my CA agent cert. I generated a PKCS#10 request. e.g. PKCS10Client -d . -p netscape -n "CN=KRA Storage Certificate,OU=testUpgrade,O=ladycfu-caRSA072820" -l 2048 -o sys_kraStorage_pkcs10_upgrade.req From browser, I went to EE portal (should be asked to authenticate using a cert; you'd want to select the RA user cert) profile list and pasted the request into each profile and submit. The cert should be returned immediately. On a related note, does the "auditSigningCert cert-pki-kra" also need to be a separate profile? In IPA it uses the profile caInternalAuthAuditSigningCert for renewals. If that's what you need, yes I could add that. I'm resetting this bug to Assigned Hi Christina, I did a quick test with the new profiles and the certs don't get renewed when I use them: # getcert list -i 20200925125218 Number of certificates and requests being tracked: 12. Request ID '20200925125218': status: MONITORING ca-error: Server at "http://server.domain.com:8080/ca/ee/ca/profileSubmit" replied: Invalid Credential. stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='storageCert cert-pki-kra',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=DOMAIN.COM subject: CN=KRA Storage Certificate,O=DOMAIN.COM expires: 2022-09-15 14:51:01 CEST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-clientAuth profile: caIPAKraStorageCert pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "storageCert cert-pki-kra" track: yes auto-renew: yes /var/log/pki/pki-tomcat/ca/debug.2020-09-25.log: 2020-09-25 14:54:33 [http-nio-8080-exec-21] WARNING: CertProcessor: No authenticator credentials required 2020-09-25 14:54:33 [http-nio-8080-exec-21] SEVERE: AgentCertAuthentication: No SSL Client Certs Found 2020-09-25 14:54:33 [http-nio-8080-exec-21] SEVERE: CAProcessor: authentication error: Invalid Credential. Invalid Credential. at com.netscape.cms.authentication.AgentCertAuthentication.authenticate(AgentCertAuthentication.java:164) at com.netscape.cms.servlet.processors.CAProcessor.authenticate(CAProcessor.java:434) at com.netscape.cms.servlet.processors.CAProcessor.authenticate(CAProcessor.java:486) at com.netscape.cms.servlet.cert.EnrollmentProcessor.processEnrollment(EnrollmentProcessor.java:178) at com.netscape.cms.servlet.cert.EnrollmentProcessor.processEnrollment(EnrollmentProcessor.java:97) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:277) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:130) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:494) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:225) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:47) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:149) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:47) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:149) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:82) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) 2020-09-25 14:54:33 [http-nio-8080-exec-21] SEVERE: ProfileSubmitServlet: authentication error in processing request: Invalid Credential. Invalid Credential. at com.netscape.cms.authentication.AgentCertAuthentication.authenticate(AgentCertAuthentication.java:164) at com.netscape.cms.servlet.processors.CAProcessor.authenticate(CAProcessor.java:434) at com.netscape.cms.servlet.processors.CAProcessor.authenticate(CAProcessor.java:486) at com.netscape.cms.servlet.cert.EnrollmentProcessor.processEnrollment(EnrollmentProcessor.java:178) at com.netscape.cms.servlet.cert.EnrollmentProcessor.processEnrollment(EnrollmentProcessor.java:97) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.processEnrollment(ProfileSubmitServlet.java:277) at com.netscape.cms.servlet.profile.ProfileSubmitServlet.process(ProfileSubmitServlet.java:130) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:494) at javax.servlet.http.HttpServlet.service(HttpServlet.java:741) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:225) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:47) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:149) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:549) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:191) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:47) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:149) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:144) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) at com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:82) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) I checked the other profiles that IPA is using to renew the certs (caSignedLogCert, caOCSPCert, caSubsystemCert...) and they define auth.class_id= instead of auth.instance_id=raCertAuth. Hi Florence, Ok, I must be mistaken in thinking that I should use the same authentication method as caIPAserviceCert. So, if it is auth.class_id= (without any value after '='), that means the profile will require manual CA agent approval. Could you confirm if that's what you want? If so, I can make the change. I'll also do the same with the audit one that Rob was asking about. Please let me know. thanks! Hi Christina, as far as I understand, the renewal for these certs is done in 2 steps from certmonger: 1/ the submission, which is not authenticated 2/ the approval, which requires the RA authentication So yes, the profile requires CA agent approval. Thanks (In reply to Florence Blanc-Renaud from comment #10) > Hi Christina, > > as far as I understand, the renewal for these certs is done in 2 steps from > certmonger: > 1/ the submission, which is not authenticated > 2/ the approval, which requires the RA authentication > > So yes, the profile requires CA agent approval. > Thanks I can't say I understand what the "2 steps" certmonger involves in regards to Dogtag. Does it mean 1. the first step sends a request (without authentication) to the CA, and 2nd step is a CA agent manually approving the request or 2. the first step sends a request to something that's not Dogtag, and the 2nd step sends a request "as a CA agent" to submit and auto-approve the request at the same time ? For case #1, if manual approval (by a CA agent) is required, then we already have generic (not specific to IPA) profiles: caStorageCert.cfg caTransportCert.cfg where auth instance is set to null, meaning, CA agent manual approval is required. In other words, I should just remove caIPAKraTransportCert.cfg and caIPAKraStorageCert.cfg, and just add a generic audit signing profile: caAuditSigningCert.cfg where auth instance is set to null: auth.instance_id= For case #2, Only step 2 concerns Dogtag. In this case, we need to keep caIPAKraTransportCert.cfg and caIPAKraStorageCert.cfg, but change the auth instance so that it's the CA agent instead of RA agent: auth.instance_id=AgentCertAuth In addition, add a caIPAAuditSigningCert.cfg with the same auth.instance_id=AgentCertAuth It would help, if you have a profile that works for you as an example. thanks. I don't know a ton about the details of this as I've never had to touch it but it's actually four steps: submit, review, approve, retrieve. Only the review and approve steps are authenticated. certmonger speaks directly to the CA. IPA is not involved. certmonger only has access to the IPA RA and I always understood that it did the issuance. (In reply to Rob Crittenden from comment #13) > I don't know a ton about the details of this as I've never had to touch it > but it's actually four steps: submit, review, approve, retrieve. Only the > review and approve steps are authenticated. certmonger speaks directly to > the CA. IPA is not involved. > > certmonger only has access to the IPA RA and I always understood that it did > the issuance. Could you maybe point me to a profile that works for you? This would take out some guessing on my part. Thanks! Here are several on the off-chance there is something special about one of them. caSignedLogCert caOCSPCert caSubsystemCert caSubsystemCert (In reply to Rob Crittenden from comment #15) > Here are several on the off-chance there is something special about one of > them. > > caSignedLogCert > caOCSPCert > caSubsystemCert > caSubsystemCert Thanks Rob! It appears that all of them have auth.class_id= so that's what I'll do then. btw, the last two examples are the same profiles. Also, as I pointed out earlier, we already have generic (not specific to IPA) profiles: caStorageCert.cfg caTransportCert.cfg where auth instance is set to null, meaning, CA agent manual approval is required. In other words, I should just remove caIPAKraTransportCert.cfg and caIPAKraStorageCert.cfg, and just add a generic audit signing profile: caAuditSigningCert.cfg where auth instance is set to null. Does this sound like a reasonable approach? I tested rewnewing the "storageCert cert-pki-kra" cert using the caStorageCert profile and it worked in the sense that the a new cert was obtained but the original had the id-kp-clientAuth EKU and the new cert did not. (In reply to Rob Crittenden from comment #18) > I tested rewnewing the "storageCert cert-pki-kra" cert using the > caStorageCert profile and it worked in the sense that the a new cert was > obtained but the original had the id-kp-clientAuth EKU and the new cert did > not. id-kp-clientAuth EKU is only needed for a cert used in TLS client authentication when acting as a client. I think we cleaned up all the profiles so it's "least privileges". If you want to have that, I'll have to create a new profile for you. Let me know. Also let me know about caTransportCert.cfg. As for audit profile, I intend to copy caInternalAuthAuditSigningCert.cfg and modify the auth value to none, so if you are particular about any attributes, you might want to give that a try and let me know if it meets your expectations. thanks. (In reply to Christina Fu from comment #19) > (In reply to Rob Crittenden from comment #18) > > I tested rewnewing the "storageCert cert-pki-kra" cert using the > > caStorageCert profile and it worked in the sense that the a new cert was > > obtained but the original had the id-kp-clientAuth EKU and the new cert did > > not. > > id-kp-clientAuth EKU is only needed for a cert used in TLS client > authentication when acting as a client. I think we cleaned up all the > profiles so it's "least privileges". Works for me. > If you want to have that, I'll have to create a new profile for you. Let me > know. I don't think we have any specific requirements other than to be able to renew the certs using certmonger. IPA doesn't use these certificates except for managing their renewal. So if the certificates and profiles work for CS then I believe that's fine for us. IPA treats the CA and KRA as black boxes. We try not to poke too far inside. > Also let me know about caTransportCert.cfg. > As for audit profile, I intend to copy caInternalAuthAuditSigningCert.cfg > and modify the auth value to none, so if you are particular about any > attributes, you might want to give that a try and let me know if it meets > your expectations. I think we'd prefer to be able to re-use existing CS profiles and not add any additional maintenance burden. If the profile is good enough for use by standalone CS then it should be good enough for IPA (generally speaking). Just to concur with (my interpretation of) what was already said: In FreeIPA for Dogtag system certificates including subsystem, audit signing, OCSP signing, KRA transport and KRA storage certs, we (FreeIPA) currently use the standard profiles shipped with Dogtag and do not wish to change that. New versions of these profiles for IPA are not needed. Furthermore, from my POV it is fine if Dogtag does upgrade these profiles to keep them up to date with best practices. Even on deployed instances - as long as they remain compatible i.e. renewing with the updated profile will not cause anything to break. These profiles are only used to issue certs that are only used within the PKI infrastructure itself, so it is possible to make incremental changes with confidence. (The OCSP cert is the exception - it is used by arbitrary clients so more care must be taken when updating that profile). If I have overlooked something please fill in the detail for me :) Thank you Rob and Fraser. Yes being able to use the default profiles would be the best approach. I'll be removing the previously added caIPAKraTransportCert.cfg and caIPAKraStorageCert.cfg, and then add a generic caAuditSigningCert.cfg commit 53e305c134e3838a12a6d034bfe188ab7e2e1b3f (HEAD -> master, origin/master, origin/HEAD) Author: Christina Fu <cfu> Date: Wed Oct 7 15:03:11 2020 -0700 Bug1875563-add profile caAuditSigningCert This patch will revert the previously added IPA specific KRA storage and transport cert prorfiles, as it turned out that they just need generic KRA storage and transport cert profiles, which could be fulfilled by using the following two existing profiles caStorageCert.cfg caTransportCert.cfg In addition, a caAuditSigningCert profile is added, although I find a misleading profile named caSignedLogCert.cfg that was intended for the use. I disabled caSignedLogCert.cfg instead. I also removed the SHA1 algorithms from all the *storage* and *audit* profiles while I'm at it. The upgrade scripts only adds the new profile caAuditSigningCert. It does not modify existing profiles or remove those two IPA specific ones. fixes https://bugzilla.redhat.com/show_bug.cgi?id=1875563 QE please note the test procedure has been changed due to change of the fix: https://bugzilla.redhat.com/show_bug.cgi?id=1883639#c3 Before: [root@pki1 ~]# rpm -qa | grep pki pki-server-10.9.4-1.module+el8.3.0+8058+d5cd4219.noarch pki-ocsp-10.9.4-1.module+el8pki+8128+140b7c6c.noarch redhat-pki-console-theme-10.9.4-1.module+el8pki+8128+140b7c6c.noarch pki-kra-10.9.4-1.module+el8.3.0+8058+d5cd4219.noarch pki-tools-10.9.4-1.module+el8.3.0+8058+d5cd4219.x86_64 python3-pki-10.9.4-1.module+el8.3.0+8058+d5cd4219.noarch pki-tks-10.9.4-1.module+el8pki+8128+140b7c6c.noarch pki-base-10.9.4-1.module+el8.3.0+8058+d5cd4219.noarch pki-ca-10.9.4-1.module+el8.3.0+8058+d5cd4219.noarch After RPM upgrade: [root@pki1 ~]# rpm -qa | grep pki pki-symkey-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.x86_64 pki-servlet-engine-9.0.30-1.module+el8.3.0+6730+8f9c6254.noarch pki-servlet-4.0-api-9.0.30-1.module+el8.3.0+6730+8f9c6254.noarch pki-server-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.noarch pki-base-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.noarch pki-kra-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.noarch pki-base-java-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.noarch idm-console-framework-1.2.0-3.module+el8pki+7130+225b0dd0.noarch pki-ca-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.noarch python3-pki-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.noarch pki-tools-10.10.0-0.2.beta1.module+el8.4.0+8460+91b0d519.x86_64 Test Procedure: https://bugzilla.redhat.com/show_bug.cgi?id=1883639#c3 Proof of concept: # pki -d /opt/pki/certdb/ -c SECret.123 -p 20443 -n CA_AgentV ca-profile-show caAuditSigningCert ---------------------------- Profile "caAuditSigningCert" ---------------------------- ProfileNotFoundException: Profile ID caAuditSigningCert not found [root@pki1 ~]# ls /var/lib/pki/topology-02-CA/ca/profiles/ca/caAuditSigningCert* ls: cannot access '/var/lib/pki/topology-02-CA/ca/profiles/ca/caAuditSigningCert*': No such file or directory After upgrade: [root@pki1 ~]# pki -d /opt/pki/certdb/ -c SECret.123 -p 20443 -n CA_AgentV ca-profile-show caAuditSigningCert ---------------------------- Profile "caAuditSigningCert" ---------------------------- Profile ID: caAuditSigningCert Name: Manual Audit Signing Certificate Enrollment Description: This certificate profile is for enrolling audit signing certificates. # ls /var/lib/pki/topology-02-CA/ca/profiles/ca/caAuditSigningCert* /var/lib/pki/topology-02-CA/ca/profiles/ca/caAuditSigningCert.cfg # pki -d /opt/pki/certdb/ -c SECret.123 -p 20443 -n "CA_AgentV" ca-cert-show 0x23 --pretty Serial Number: 0x23 Subject DN: CN=testuser,OU=people,DC=example,DC=com Issuer DN: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org Status: VALID Not Valid Before: Wed Nov 04 12:42:37 EST 2020 Not Valid After: Tue Oct 25 12:42:37 EDT 2022 Certificate: Data: Version: v3 Serial Number: 0x23 Signature Algorithm: SHA512withRSA - 1.2.840.113549.1.1.13 Issuer: CN=CA Signing Certificate,OU=topology-02-CA,O=topology-02_Foobarmaster.org Validity: Not Before: Wednesday, November 4, 2020 12:42:37 PM EST America/New_York Not After: Tuesday, October 25, 2022 12:42:37 PM EDT America/New_York Subject: CN=testuser,OU=people,DC=example,DC=com Subject Public Key Info: Algorithm: RSA - 1.2.840.113549.1.1.1 Public Key: Exponent: 65537 Public Key Modulus: (2048 bits) : AF:3C:43:A0:31:BC:6F:83:48:D1:AA:65:B3:1D:A2:66: 10:5D:43:ED:92:AD:61:02:9D:16:87:1D:D2:4E:D5:20: 78:77:C1:CE:87:D0:30:1E:F1:3A:75:CD:44:44:43:19: 06:43:AF:92:78:03:6B:D2:08:84:CA:62:65:1E:9E:51: 45:3F:A3:6E:C9:68:2D:F9:52:BC:08:E7:64:75:E7:14: 87:1C:82:45:C8:E4:8E:F7:06:85:1F:F6:24:DD:C4:5A: 2B:5D:02:74:5C:A0:56:92:A2:0C:5F:A7:9A:0D:4B:DE: 35:E0:F7:0B:1A:05:52:C6:6A:18:48:F5:46:93:88:39: FE:E0:13:06:9B:38:9C:DE:E2:54:32:60:6E:33:A2:8B: 15:8D:63:C0:CB:66:38:F6:9B:6A:92:87:59:0E:3C:C1: 05:C9:9F:7A:14:54:09:D9:C2:72:2D:4B:A8:CD:44:75: 13:2F:BB:08:31:C9:54:3D:2B:C6:18:B5:A5:07:6E:D6: CD:E2:ED:31:66:50:55:99:47:E9:87:FC:51:97:65:A4: 12:11:1B:6F:D0:E9:68:96:53:F3:BB:CA:62:0E:51:C9: 3D:4D:DF:94:94:27:D0:41:40:9E:4B:E7:E4:4A:A2:C9: EE:5E:C8:CE:D3:B1:CF:E9:99:EA:2F:4E:4F:2F:98:1F Extensions: Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 61:97:DB:55:C3:C2:19:1C:8D:14:7B:B7:FE:E4:0A:43: 03:DC:15:B9 Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://pki1.example.com:20080/ca/ocsp Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Non Repudiation Signature: Algorithm: SHA512withRSA - 1.2.840.113549.1.1.13 Signature: D7:E3:AD:61:60:04:F5:60:D2:67:C8:58:94:F1:63:72: 27:A3:55:F5:63:6F:D1:CF:47:EC:D1:53:D9:60:FC:B7: FD:2D:A3:E1:0C:0D:0D:79:2D:6C:09:06:7F:20:64:ED: 63:B8:15:02:19:0A:2A:33:61:C9:8D:A1:02:B5:59:A4: B9:21:01:92:2F:3C:0D:7F:24:2B:1E:93:8A:77:56:BC: E4:2B:C8:00:FC:9C:49:C3:ED:B5:FA:20:77:89:F1:BE: 74:03:F1:9B:EE:62:10:5B:7E:D8:AA:3A:25:39:3D:71: 23:7B:16:08:6E:93:0D:AE:F0:30:65:A5:77:97:66:25: D6:F8:B7:91:E1:7B:7F:70:DB:3D:D9:C6:03:47:AE:FD: FC:B8:A0:73:5A:A1:CC:32:D3:C2:33:EF:B1:76:01:57: 40:3F:C2:48:94:A2:35:FB:37:73:77:4B:2C:92:7F:96: 98:77:70:4D:99:62:F8:FC:20:46:A2:AE:FA:A8:33:74: 64:10:3D:3B:90:FE:30:46:A8:77:EE:67:7B:DE:6A:95: DE:09:84:B3:0C:FC:C7:0E:1C:7F:BF:50:7C:56:D3:CC: C8:13:A7:AE:EF:E4:DC:C0:BC:24:94:2B:A8:52:4B:1B: 46:E8:D2:CB:9A:5A:A4:DE:BD:10:8A:49:2A:16:E5:DC FingerPrint MD2: 1C:36:CD:18:D0:07:D7:8B:C4:01:7A:A0:0B:57:32:E4 MD5: 5B:47:81:8D:0E:D8:78:45:49:AE:EE:34:35:AE:87:8B SHA-1: 5E:CC:C9:C4:5C:91:41:25:9F:B2:5E:58:C3:34:7F:75: CD:81:F6:4D SHA-256: 96:99:3D:5B:C3:06:1E:FE:47:43:C5:9E:BF:BE:87:C5: B7:5F:74:17:11:1B:52:6E:7A:AF:56:06:00:D6:F6:35 SHA-512: 17:58:02:A4:7B:6B:AA:6E:86:72:36:66:6E:FC:EF:6E: DE:4D:35:A2:E3:1C:68:0C:83:DB:59:07:1F:C0:07:4E: 6E:3B:54:0F:52:5A:4A:C9:A3:E6:DA:FB:9A:F6:9F:EE: 17:A9:D7:4C:C9:EF:F8:4B:08:ED:55:19:76:C1:33:1F Based on above test result, marking this Bugzilla verified. 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 (Moderate: pki-core:10.6 and pki-deps:10.6 security, bug fix, and enhancement update), 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/RHSA-2021:1775 |