From aleksey.chudov at gmail.com Wed Sep 2 08:05:52 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Wed, 2 Sep 2015 11:05:52 +0300 Subject: [Pki-users] How to setup PKI CA to ask for passwords at startup? In-Reply-To: References: <1440615963.23248.139.camel@redhat.com> Message-ID: One big difference in starting PKI under nuxwdog control is that pki-tomcatd at pki-tomcat.service starts PKI as pkiuser:pkiuser but pki-tomcatd-nuxwdog at pki-tomcat.service starts PKI as root:root. Running PKI as root user is bad idea. On Thu, Aug 27, 2015 at 2:33 PM, Aleksey Chudov wrote: > To begin with I have updated to version 10.2.6 from F22 testing to get > pki-server man pages. > > Enabling nuxwdog solves the problem. Thank you! > > On Wed, Aug 26, 2015 at 10:06 PM, Ade Lee wrote: > >> Aleksey, >> >> password prompting in CS 8.1 worked because of a utility program called >> nuxwdog which would prompt for passwords. >> >> We have done some work to get nuxwdog working with the latest Dogtag >> code, but there is some setup required. >> Fortunately, all that setup has been encapsulated in the pki-server >> utility. >> >> For details, man pki-server , man pki-server-instance and man >> pki-server-nuxwdog. >> >> The specific command would be: >> pki-server instance-nuxwdog-enable >> >> You should then be prompted for the passwords, and can remove your >> password.conf file. >> >> Ade >> On Wed, 2015-08-26 at 21:49 +0300, Aleksey Chudov wrote: >> >> I'm looking at removing at least nss password but both nss and 389 >> passwords will be better. >> >> Actually PKI prompts for password but I don't see the prompt because of >> systemd. >> >> To reproduce >> >> systemctl stop pki-tomcatd at pki-tomcat.service >> sed -i.bak '/internal=/d' /etc/pki/pki-tomcat/password.conf >> systemctl start pki-tomcatd at pki-tomcat.service >> >> /var/log/messages >> Aug 26 21:37:33 srv333 server[8889]: Enter password for Internal Key >> Storage Token >> >> /var/log/pki/pki-tomcat/ca/debug >> [26/Aug/2015:21:37:52][localhost-startStop-1]: Got token Internal Key >> Storage Token by name >> [26/Aug/2015:21:37:52][localhost-startStop-1]: SigningUnit init: debug >> org.mozilla.jss.util.IncorrectPasswordException >> Invalid Password >> at com.netscape.ca.SigningUnit.init(SigningUnit.java:192) >> at >> com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1229) >> at >> com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:342) >> at >> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1107) >> at >> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1013) >> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:520) >> at com.netscape.certsrv.apps.CMS.init(CMS.java:187) >> at com.netscape.certsrv.apps.CMS.start(CMS.java:1601) >> at >> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) >> at javax.servlet.GenericServlet.init(GenericServlet.java:158) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at >> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) >> at >> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) >> at java.security.AccessController.doPrivileged(Native Method) >> at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) >> at >> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) >> at >> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) >> at >> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) >> at >> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) >> at >> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) >> at >> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) >> at >> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) >> at >> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) >> at >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) >> at >> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) >> at >> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) >> at >> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) >> at >> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) >> at >> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) >> at >> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) >> at >> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at java.lang.Thread.run(Thread.java:745) >> [26/Aug/2015:21:37:52][localhost-startStop-1]: CMSEngine.shutdown() >> >> >> On Wed, Aug 26, 2015 at 8:09 PM, Dave Sirrine >> wrote: >> >> Aleksey, >> >> Did removing the password from the file not cause the system to prompt >> you for the password at startup. Also, are you looking at doing both nss >> and 389 passwords? >> >> -- David >> On Aug 26, 2015 5:58 AM, "Aleksey Chudov" >> wrote: >> >> Hi, >> >> The password.conf file stores system passwords in plaintext, and I >> prefer to enter system passwords manually and to remove the password file. >> >> I have found original documentation >> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/System_Passwords.html. >> But it is for older version on PKI and does not work with systemd. >> >> How to setup PKI CA to ask for NSS DB password at startup? >> >> Packages versions (I have rebuilt F22 packages for CentOS 7): >> # rpm -qa | grep pki >> pki-base-10.2.5-1.el7.centos.noarch >> pki-server-10.2.5-1.el7.centos.noarch >> dogtag-pki-server-theme-10.2.5-1.el7.centos.noarch >> pki-ca-10.2.5-1.el7.centos.noarch >> pki-tools-10.2.5-1.el7.centos.x86_64 >> dogtag-pki-console-theme-10.2.5-1.el7.centos.noarch >> >> Aleksey >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> >> >> >> _______________________________________________ >> Pki-users mailing listPki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.chudov at gmail.com Wed Sep 2 08:43:30 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Wed, 2 Sep 2015 11:43:30 +0300 Subject: [Pki-users] How to setup PKI CA to ask for passwords at startup? In-Reply-To: References: <1440615963.23248.139.camel@redhat.com> Message-ID: Below is quick instruction of how to run pki-tomcatd-nuxwdog at pki-tomcat.service as pkiuser:pkiuser in case it will be useful for someone systemctl stop pki-tomcatd-nuxwdog at pki-tomcat.service groupadd -r systemd-ask-password usermod -a -G systemd-ask-password pkiuser echo "d /run/systemd/ask-password 0775 root systemd-ask-password -" > /etc/tmpfiles.d/systemd-ask-password.conf /usr/bin/systemd-tmpfiles --create systemd-ask-password.conf mkdir /etc/systemd/system/pki-tomcatd-nuxwdog at .service.d/ cat << EOF > /etc/systemd/system/pki-tomcatd-nuxwdog at .service.d/override.conf [Service] User=pkiuser Group=pkiuser EOF systemctl daemon-reload find /var/lib/pki/ /var/log/pki/ /etc/pki/pki-*/ -exec chown pkiuser:pkiuser {} + systemctl start pki-tomcatd-nuxwdog at pki-tomcat.service On Wed, Sep 2, 2015 at 11:05 AM, Aleksey Chudov wrote: > One big difference in starting PKI under nuxwdog control is that > pki-tomcatd at pki-tomcat.service starts PKI as pkiuser:pkiuser but > pki-tomcatd-nuxwdog at pki-tomcat.service starts PKI as root:root. Running > PKI as root user is bad idea. > > > > > On Thu, Aug 27, 2015 at 2:33 PM, Aleksey Chudov > wrote: > >> To begin with I have updated to version 10.2.6 from F22 testing to get >> pki-server man pages. >> >> Enabling nuxwdog solves the problem. Thank you! >> >> On Wed, Aug 26, 2015 at 10:06 PM, Ade Lee wrote: >> >>> Aleksey, >>> >>> password prompting in CS 8.1 worked because of a utility program called >>> nuxwdog which would prompt for passwords. >>> >>> We have done some work to get nuxwdog working with the latest Dogtag >>> code, but there is some setup required. >>> Fortunately, all that setup has been encapsulated in the pki-server >>> utility. >>> >>> For details, man pki-server , man pki-server-instance and man >>> pki-server-nuxwdog. >>> >>> The specific command would be: >>> pki-server instance-nuxwdog-enable >>> >>> You should then be prompted for the passwords, and can remove your >>> password.conf file. >>> >>> Ade >>> On Wed, 2015-08-26 at 21:49 +0300, Aleksey Chudov wrote: >>> >>> I'm looking at removing at least nss password but both nss and 389 >>> passwords will be better. >>> >>> Actually PKI prompts for password but I don't see the prompt because of >>> systemd. >>> >>> To reproduce >>> >>> systemctl stop pki-tomcatd at pki-tomcat.service >>> sed -i.bak '/internal=/d' /etc/pki/pki-tomcat/password.conf >>> systemctl start pki-tomcatd at pki-tomcat.service >>> >>> /var/log/messages >>> Aug 26 21:37:33 srv333 server[8889]: Enter password for Internal Key >>> Storage Token >>> >>> /var/log/pki/pki-tomcat/ca/debug >>> [26/Aug/2015:21:37:52][localhost-startStop-1]: Got token Internal Key >>> Storage Token by name >>> [26/Aug/2015:21:37:52][localhost-startStop-1]: SigningUnit init: debug >>> org.mozilla.jss.util.IncorrectPasswordException >>> Invalid Password >>> at com.netscape.ca.SigningUnit.init(SigningUnit.java:192) >>> at >>> com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1229) >>> at >>> com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:342) >>> at >>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1107) >>> at >>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1013) >>> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:520) >>> at com.netscape.certsrv.apps.CMS.init(CMS.java:187) >>> at com.netscape.certsrv.apps.CMS.start(CMS.java:1601) >>> at >>> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) >>> at javax.servlet.GenericServlet.init(GenericServlet.java:158) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:606) >>> at >>> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) >>> at >>> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) >>> at >>> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) >>> at >>> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) >>> at >>> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) >>> at >>> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) >>> at >>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) >>> at >>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) >>> at >>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) >>> at >>> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) >>> at >>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) >>> at >>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) >>> at >>> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) >>> at >>> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) >>> at >>> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at >>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) >>> at >>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) >>> at >>> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) >>> at >>> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> at java.lang.Thread.run(Thread.java:745) >>> [26/Aug/2015:21:37:52][localhost-startStop-1]: CMSEngine.shutdown() >>> >>> >>> On Wed, Aug 26, 2015 at 8:09 PM, Dave Sirrine >>> wrote: >>> >>> Aleksey, >>> >>> Did removing the password from the file not cause the system to prompt >>> you for the password at startup. Also, are you looking at doing both nss >>> and 389 passwords? >>> >>> -- David >>> On Aug 26, 2015 5:58 AM, "Aleksey Chudov" >>> wrote: >>> >>> Hi, >>> >>> The password.conf file stores system passwords in plaintext, and I >>> prefer to enter system passwords manually and to remove the password file. >>> >>> I have found original documentation >>> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/System_Passwords.html. >>> But it is for older version on PKI and does not work with systemd. >>> >>> How to setup PKI CA to ask for NSS DB password at startup? >>> >>> Packages versions (I have rebuilt F22 packages for CentOS 7): >>> # rpm -qa | grep pki >>> pki-base-10.2.5-1.el7.centos.noarch >>> pki-server-10.2.5-1.el7.centos.noarch >>> dogtag-pki-server-theme-10.2.5-1.el7.centos.noarch >>> pki-ca-10.2.5-1.el7.centos.noarch >>> pki-tools-10.2.5-1.el7.centos.x86_64 >>> dogtag-pki-console-theme-10.2.5-1.el7.centos.noarch >>> >>> Aleksey >>> >>> _______________________________________________ >>> Pki-users mailing list >>> Pki-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-users >>> >>> >>> >>> _______________________________________________ >>> Pki-users mailing listPki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.chudov at gmail.com Wed Sep 2 12:04:59 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Wed, 2 Sep 2015 15:04:59 +0300 Subject: [Pki-users] CRL to file publishing on Clone CA Message-ID: Hi, I have configured the same rules for CRL publishing on Master CA and two Clone CAs +ca.publish.enable=true +ca.publish.ldappublish.enable=false +ca.publish.publisher.instance.FileCrlPublisher.Filename.b64=false +ca.publish.publisher.instance.FileCrlPublisher.Filename.der=true +ca.publish.publisher.instance.FileCrlPublisher.crlLinkExt=crl +ca.publish.publisher.instance.FileCrlPublisher.directory=/var/lib/pki/pki-tomcat/webapps/crl +ca.publish.publisher.instance.FileCrlPublisher.latestCrlLink=true +ca.publish.publisher.instance.FileCrlPublisher.pluginName=FileBasedPublisher +ca.publish.publisher.instance.FileCrlPublisher.timeStamp=LocalTime +ca.publish.publisher.instance.FileCrlPublisher.zipCRLs=false +ca.publish.publisher.instance.FileCrlPublisher.zipLevel=9 +ca.publish.rule.instance.FileCrlRule.enable=true +ca.publish.rule.instance.FileCrlRule.mapper=NoMap +ca.publish.rule.instance.FileCrlRule.pluginName=Rule +ca.publish.rule.instance.FileCrlRule.predicate= +ca.publish.rule.instance.FileCrlRule.publisher=FileCrlPublisher +ca.publish.rule.instance.FileCrlRule.type=crl But only Master CA publishes CRLs to /var/lib/pki/pki-tomcat/webapps/crl directory. According to documentation https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/9/html/Planning_Installation_and_Deployment_Guide/Cloning_a_Subsystem.html#cloning-for-cas, only one replicated CA can generate, cache, and publish CRLs. What are the best practices of publishing CRLs on Clone CA? Should I just sync CRL directory on both clones from master, or is there a better approach? Aleksey -------------- next part -------------- An HTML attachment was scrubbed... URL: From lachen at redhat.com Wed Sep 2 17:27:05 2015 From: lachen at redhat.com (Lan Chen) Date: Wed, 2 Sep 2015 13:27:05 -0400 (EDT) Subject: [Pki-users] Dogtag 10.1 API In-Reply-To: <625987450.12482137.1441214487694.JavaMail.zimbra@redhat.com> References: <625987450.12482137.1441214487694.JavaMail.zimbra@redhat.com> Message-ID: <2012342168.12483885.1441214825755.JavaMail.zimbra@redhat.com> Hi All, Is there good documentation on Dogtag 10.1 API somewhere? Lan ----- Original Message ----- From: "Ryan Murray" To: "Lan Chen" Sent: Wednesday, September 2, 2015 9:53:09 AM Subject: Re: Dogtag 10.1 There is a massive difference between the API's, I checked before raising the concern. By massive I mean they are all different. Example: 10.1 Noun=certs 10.2 Noun=certificates None of the other nouns are working as documented by 10.2. On Sep 2, 2015 9:50 AM, "Lan Chen" < lachen at redhat.com > wrote: Ryan, I just checked with Paul, we need it installed on RHEL. Could you see if the APIs documented for 10.2 also works for 10.1, there shouldn't be too big of a difference between the versions. From: "Ryan Murray" < rmurray at stonedoorgroup.com > To: "Lan Chen" < lachen at redhat.com > Sent: Wednesday, September 2, 2015 9:38:25 AM Subject: Re: Dogtag 10.1 The packages are not avaliable to the RHEL 7 channels or EPEL channels. From a technical standpoint I would need to spend time getting the exact limitations, but as it stands I would have to install tons of fedora packages or compile from source to get 10.2 running on RHEL. On Wednesday, September 2, 2015, Lan Chen < lachen at redhat.com > wrote:
I meant why can't 10.2 be on RHEL, and need to be on Fedora? From: "Ryan Murray" < rmurray at stonedoorgroup.com > To: "Lan Chen" < lachen at redhat.com > Sent: Wednesday, September 2, 2015 9:33:08 AM Subject: Re: Dogtag 10.1 There is no issue with the install, that was done Monday night. The issue is with the API not being documented. The client had to use fedora in all of their tests due to the newer 10.2 version and better API. On Wednesday, September 2, 2015, Lan Chen < lachen at redhat.com > wrote:
What's the issue on installing Dogtag 10.2 on RHEL? From: "Ryan Murray" < rmurray at stonedoorgroup.com > To: "Lan Chen" < lachen at redhat.com > Sent: Wednesday, September 2, 2015 8:02:27 AM Subject: Dogtag 10.1 Hi Lan, Could you please see if there is anyone at Red Hat technical that would have any documentation on the dog tag 10.1 API? It is not documented online that I can find. Hunting through source code to find undocumented API calls is a stretch on the SOW, and installing Fedora is a change to needs Red Hat's OK. Thanks
-------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Sep 2 19:17:57 2015 From: jmagne at redhat.com (John Magne) Date: Wed, 2 Sep 2015 15:17:57 -0400 (EDT) Subject: [Pki-users] CRL to file publishing on Clone CA In-Reply-To: References: Message-ID: <1607308522.36937554.1441221477324.JavaMail.zimbra@redhat.com> Hi: I'm not sure what are try to accomplish. The way we have it now, only the master publishes anywhere. Is the concern over the internal OCSP of the cloned CA's or are you publishing to some external OSCP responders? If you are worried about the internal OCSP's of the clones, they should give the correct answers about a given cert through replication. If there is something else desired, let us know. thanks, jack ----- Original Message ----- > From: "Aleksey Chudov" > To: pki-users at redhat.com > Sent: Wednesday, September 2, 2015 5:04:59 AM > Subject: [Pki-users] CRL to file publishing on Clone CA > > Hi, > > I have configured the same rules for CRL publishing on Master CA and two > Clone CAs > > +ca.publish.enable=true > +ca.publish.ldappublish.enable=false > +ca.publish.publisher.instance.FileCrlPublisher.Filename.b64=false > +ca.publish.publisher.instance.FileCrlPublisher.Filename.der=true > +ca.publish.publisher.instance.FileCrlPublisher.crlLinkExt=crl > +ca.publish.publisher.instance.FileCrlPublisher.directory=/var/lib/pki/pki-tomcat/webapps/crl > +ca.publish.publisher.instance.FileCrlPublisher.latestCrlLink=true > +ca.publish.publisher.instance.FileCrlPublisher.pluginName=FileBasedPublisher > +ca.publish.publisher.instance.FileCrlPublisher.timeStamp=LocalTime > +ca.publish.publisher.instance.FileCrlPublisher.zipCRLs=false > +ca.publish.publisher.instance.FileCrlPublisher.zipLevel=9 > +ca.publish.rule.instance.FileCrlRule.enable=true > +ca.publish.rule.instance.FileCrlRule.mapper=NoMap > +ca.publish.rule.instance.FileCrlRule.pluginName=Rule > +ca.publish.rule.instance.FileCrlRule.predicate= > +ca.publish.rule.instance.FileCrlRule.publisher=FileCrlPublisher > +ca.publish.rule.instance.FileCrlRule.type=crl > > But only Master CA publishes CRLs to /var/lib/pki/pki-tomcat/webapps/crl > directory. > > According to documentation > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/9/html/Planning_Installation_and_Deployment_Guide/Cloning_a_Subsystem.html#cloning-for-cas > , only one replicated CA can generate, cache, and publish CRLs. > > What are the best practices of publishing CRLs on Clone CA? Should I just > sync CRL directory on both clones from master, or is there a better > approach? > > Aleksey > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From edewata at redhat.com Wed Sep 2 19:33:09 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 2 Sep 2015 14:33:09 -0500 Subject: [Pki-users] Possible PKI LDAP connections leak? In-Reply-To: References: Message-ID: <55E74EF5.7000104@redhat.com> Hi, Thanks for reporting this. I think it is a problem and I was able to reproduce it. I have filed a ticket for this issue: https://fedorahosted.org/pki/ticket/1601 Thanks again! -- Endi S. Dewata On 8/28/2015 2:21 PM, Aleksey Chudov wrote: > To clarify it is possible to DOS the Certificate System repeatedly > calling /ca/rest/securityDomain/domainInfo url until Direcrory Server > exhausts all available connections. > > > $ rpm -qa 389* pki* | sort > 389-ds-base-1.3.3.1-20.el7_1.x86_64 > 389-ds-base-libs-1.3.3.1-20.el7_1.x86_64 > pki-base-10.2.6-7.el7.centos.noarch > pki-ca-10.2.6-7.el7.centos.noarch > pki-server-10.2.6-7.el7.centos.noarch > pki-tools-10.2.6-7.el7.centos.x86_64 > > > On Thu, Aug 27, 2015 at 6:15 PM, Aleksey Chudov > > wrote: > > Hi, > > I have found possible PKI LDAP connections leak on access to > /ca/rest/securityDomain/domainInfo url. > > To reproduce > > # ss -ant state established sport = :636 > Recv-Q Send-Q Local Address:Port Peer Address:Port > 0 0 10.172.3.13:636 10.172.3.13:57696 > > 0 0 10.172.3.13:636 10.172.3.13:57692 > > 0 0 10.172.3.13:636 10.172.3.13:57695 > > 0 0 10.172.3.13:636 10.172.3.13:57690 > > 0 0 10.172.3.13:636 10.172.3.13:57689 > > 0 0 10.172.3.13:636 10.172.3.13:57693 > > 0 0 10.172.3.13:636 10.172.3.13:57688 > > 0 0 10.172.3.13:636 10.172.3.13:57691 > > 0 0 10.172.3.13:636 10.172.3.13:57687 > > > # ss -ant state established sport = :636 | wc -l > 10 > > # for ((i=0; i<256; i++)); do curl > http://localhost/ca/rest/securityDomain/domainInfo &>/dev/null; done > > # ss -ant state established sport = :636 | wc -l > 266 > > Every request to /ca/rest/securityDomain/domainInfo url increases > number on LDAP connections and produces the same message in debug log > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SessionContextInterceptor: Not authenticated. > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > AuthMethodInterceptor: SecurityDomainResource.getDomainInfo() > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > AuthMethodInterceptor: mapping: default > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > AuthMethodInterceptor: required auth methods: [*] > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > AuthMethodInterceptor: anonymous access allowed > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > ACLInterceptor: SecurityDomainResource.getDomainInfo() > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > ACLInterceptor.filter: no authorization required > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > ACLInterceptor: No ACL mapping; authz not required. > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SignedAuditEventFactory: create() > message=[AuditEvent=AUTHZ_SUCCESS][SubjectID=$Unidentified$][Outcome=Success][aclResource=null][Op=null][Info=ACL > mapping not found; OK:SecurityDomainResource.getDomainInfo] > authorization success > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > MessageFormatInterceptor: SecurityDomainResource.getDomainInfo() > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > MessageFormatInterceptor: content-type: null > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > MessageFormatInterceptor: accept: [*/*] > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > MessageFormatInterceptor: response format: application/xml > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: according to > ccMode, authorization for servlet: securitydomain is LDAP based, not > XML {1}, use default authz mgr: {2}. > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: Creating > LdapBoundConnFactor(SecurityDomainProcessor) > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > LdapBoundConnFactory: init > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > LdapBoundConnFactory:doCloning true > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init() > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init begins > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init: prompt is internaldb > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init: try getting from memory cache > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init: got password from memory > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init: password found for prompt. > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > password ok: store in memory cache > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: LdapAuthInfo: > init ends > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: init: before > makeConnection errorIfDown is false > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > makeConnection: errorIfDown false > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: SSL handshake > happened > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: Established > LDAP connection using basic authentication to host > srv334.example.com port 636 as > cn=Directory Manager > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: initializing > with mininum 3 and maximum 15 connections to host srv334.example.com > port 636, secure connection, true, > authentication type 1 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: increasing > minimum connections by 3 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: new total > available connections 3 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: new number of > connections 3 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: In > LdapBoundConnFactory::getConn() > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: masterConn is > connected: true > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: getConn: conn > is connected true > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: getConn: > mNumConns now 2 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: name: Company LLC > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: subtype: CA > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - cn=srv333.example.com:8443 > ,cn=CAList,ou=Security > Domain,o=pki-tomcat-CA > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - DomainManager: TRUE > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - cn: srv333.example.com:8443 > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SubsystemName: CA srv333.example.com > 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - Clone: FALSE > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - UnSecurePort: 8080 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureEEClientAuthPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureAdminPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureAgentPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecurePort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - host: srv333.example.com > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - objectClass: top > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - cn=srv334.example.com:8443 > ,cn=CAList,ou=Security > Domain,o=pki-tomcat-CA > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - objectClass: top > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - cn: srv334.example.com:8443 > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - host: srv334.example.com > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecurePort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureAgentPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureAdminPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - UnSecurePort: 8080 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureEEClientAuthPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - DomainManager: TRUE > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - Clone: TRUE > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SubsystemName: CA srv334.example.com > 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - cn=srv335.example.com:8443 > ,cn=CAList,ou=Security > Domain,o=pki-tomcat-CA > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - objectClass: top > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - cn: srv335.example.com:8443 > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - host: srv335.example.com > > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecurePort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureAgentPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureAdminPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - UnSecurePort: 8080 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SecureEEClientAuthPort: 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - DomainManager: TRUE > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - Clone: TRUE > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: - SubsystemName: CA srv335.example.com > 8443 > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: subtype: OCSP > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: subtype: KRA > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: subtype: RA > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: subtype: TKS > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: > SecurityDomainProcessor: subtype: TPS > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: Releasing > ldap connection > [27/Aug/2015:18:04:00][ajp-bio-127.0.0.1-8009-exec-6]: returnConn: > mNumConns now 3 > > > At the same time requests to different urls does not increase the > number of established LDAP connections. > > Is it a bug or expected behavior? > > Aleksey > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From mharmsen at redhat.com Wed Sep 2 20:47:55 2015 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 2 Sep 2015 14:47:55 -0600 Subject: [Pki-users] How to setup PKI CA to ask for passwords at startup? In-Reply-To: References: <1440615963.23248.139.camel@redhat.com> Message-ID: <55E7607B.6090502@redhat.com> Aleksey, Thanks for the instruction. Would you be willing to file a PKI TRAC Ticket on this: * https://fedorahosted.org/pki/newticket In general, we triage these tickets on a weekly basis, and assign it to an appropriate release. For this specific ticket, although an actual fix may be a ways off, we generally try to get this type of information documented as a workaround in the near term. Thanks, -- Matt On 09/02/15 02:43, Aleksey Chudov wrote: > Below is quick instruction of how to run > pki-tomcatd-nuxwdog at pki-tomcat.service as pkiuser:pkiuser in case it > will be useful for someone > > > systemctl stop pki-tomcatd-nuxwdog at pki-tomcat.service > > groupadd -r systemd-ask-password > > usermod -a -G systemd-ask-password pkiuser > > echo "d /run/systemd/ask-password 0775 root systemd-ask-password -" > > /etc/tmpfiles.d/systemd-ask-password.conf > > /usr/bin/systemd-tmpfiles --create systemd-ask-password.conf > > mkdir /etc/systemd/system/pki-tomcatd-nuxwdog at .service.d/ > > cat << EOF > > /etc/systemd/system/pki-tomcatd-nuxwdog at .service.d/override.conf > [Service] > User=pkiuser > Group=pkiuser > EOF > > systemctl daemon-reload > > find /var/lib/pki/ /var/log/pki/ /etc/pki/pki-*/ -exec chown > pkiuser:pkiuser {} + > > systemctl start pki-tomcatd-nuxwdog at pki-tomcat.service > > > > > On Wed, Sep 2, 2015 at 11:05 AM, Aleksey Chudov > > wrote: > > One big difference in starting PKI under nuxwdog control is that > pki-tomcatd at pki-tomcat.service starts PKI as pkiuser:pkiuser but > pki-tomcatd-nuxwdog at pki-tomcat.service starts PKI as root:root. > Running PKI as root user is bad idea. > > > > > On Thu, Aug 27, 2015 at 2:33 PM, Aleksey Chudov > > wrote: > > To begin with I have updated to version 10.2.6 from F22 > testing to get pki-server man pages. > > Enabling nuxwdog solves the problem. Thank you! > > On Wed, Aug 26, 2015 at 10:06 PM, Ade Lee > wrote: > > Aleksey, > > password prompting in CS 8.1 worked because of a utility > program called nuxwdog which would prompt for passwords. > > We have done some work to get nuxwdog working with the > latest Dogtag code, but there is some setup required. > Fortunately, all that setup has been encapsulated in the > pki-server utility. > > For details, man pki-server , man pki-server-instance and > man pki-server-nuxwdog. > > The specific command would be: > pki-server instance-nuxwdog-enable pki-tomcat> > > You should then be prompted for the passwords, and can > remove your password.conf file. > > Ade > On Wed, 2015-08-26 at 21:49 +0300, Aleksey Chudov wrote: >> I'm looking at removing at least nss password but both >> nss and 389 passwords will be better. >> >> Actually PKI prompts for password but I don't see the >> prompt because of systemd. >> >> To reproduce >> >> systemctl stop pki-tomcatd at pki-tomcat.service >> sed -i.bak '/internal=/d' /etc/pki/pki-tomcat/password.conf >> systemctl start pki-tomcatd at pki-tomcat.service >> >> /var/log/messages >> Aug 26 21:37:33 srv333 server[8889]: Enter password for >> Internal Key Storage Token >> >> /var/log/pki/pki-tomcat/ca/debug >> [26/Aug/2015:21:37:52][localhost-startStop-1]: Got token >> Internal Key Storage Token by name >> [26/Aug/2015:21:37:52][localhost-startStop-1]: >> SigningUnit init: debug >> org.mozilla.jss.util.IncorrectPasswordException >> Invalid Password >> at >> com.netscape.ca.SigningUnit.init(SigningUnit.java:192) >> at >> com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1229) >> at >> com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:342) >> at >> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1107) >> at >> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1013) >> at >> com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:520) >> at com.netscape.certsrv.apps.CMS.init(CMS.java:187) >> at com.netscape.certsrv.apps.CMS.start(CMS.java:1601) >> at >> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) >> at >> javax.servlet.GenericServlet.init(GenericServlet.java:158) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at >> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) >> at >> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) >> at >> java.security.AccessController.doPrivileged(Native Method) >> at >> javax.security.auth.Subject.doAsPrivileged(Subject.java:536) >> at >> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) >> at >> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) >> at >> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) >> at >> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) >> at >> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) >> at >> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) >> at >> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) >> at >> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) >> at >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) >> at >> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) >> at >> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) >> at >> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) >> at >> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) >> at >> java.security.AccessController.doPrivileged(Native Method) >> at >> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) >> at >> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) >> at >> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) >> at >> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >> at >> java.util.concurrent.FutureTask.run(FutureTask.java:262) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> at java.lang.Thread.run(Thread.java:745) >> [26/Aug/2015:21:37:52][localhost-startStop-1]: >> CMSEngine.shutdown() >> >> >> On Wed, Aug 26, 2015 at 8:09 PM, Dave Sirrine >> > wrote: >>> >>> Aleksey, >>> >>> Did removing the password from the file not cause the >>> system to prompt you for the password at startup. Also, >>> are you looking at doing both nss and 389 passwords? >>> >>> -- David >>> >>> On Aug 26, 2015 5:58 AM, "Aleksey Chudov" >>> >> > wrote: >>>> Hi, >>>> >>>> The |password.conf| file stores system passwords in >>>> plaintext, and I prefer to enter system passwords >>>> manually and to remove the password file. >>>> >>>> I have found original documentation >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/System_Passwords.html. >>>> But it is for older version on PKI and does not work >>>> with systemd. >>>> >>>> How to setup PKI CA to ask for NSS DB password at startup? >>>> >>>> Packages versions (I have rebuilt F22 packages for >>>> CentOS 7): >>>> # rpm -qa | grep pki >>>> pki-base-10.2.5-1.el7.centos.noarch >>>> pki-server-10.2.5-1.el7.centos.noarch >>>> dogtag-pki-server-theme-10.2.5-1.el7.centos.noarch >>>> pki-ca-10.2.5-1.el7.centos.noarch >>>> pki-tools-10.2.5-1.el7.centos.x86_64 >>>> dogtag-pki-console-theme-10.2.5-1.el7.centos.noarch >>>> >>>> Aleksey >>>> >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-users >>> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users > > > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.chudov at gmail.com Wed Sep 2 21:07:20 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Thu, 3 Sep 2015 00:07:20 +0300 Subject: [Pki-users] CRL to file publishing on Clone CA In-Reply-To: <1607308522.36937554.1441221477324.JavaMail.zimbra@redhat.com> References: <1607308522.36937554.1441221477324.JavaMail.zimbra@redhat.com> Message-ID: To make it clear I have to tell a bit more about my CA scheme. I have three servers, Master CA + two Clone CAs. All three servers have their own DNS names and also shared DNS name ca.local.mycompany.com. So, ca.local.mycompany.com resolves to three ip addresses for load sharing and high availability. All CA enrolled certificates contains extensions X509v3 CRL Distribution Points: Full Name: URI:http://ca.local.mycompany.com/crl/MasterCRL.crl Authority Information Access: OCSP - URI:http://ca.local.mycompany.com /ca/ocsp There is no problems with OCSP. It works out of the box. http://ca.local.mycompany.com/crl/ URL internally points to local directory on all three servers # grep -A1 crl /etc/pki/pki-tomcat/server.xml I need the CRL file to be available on all three servers for http://ca.local.mycompany.com/crl/MasterCRL.crl URL to work. So, I have configured CRL publishing to file in /var/lib/pki/pki-tomcat/webapps/crl directory on all three servers. But only Master CA actually publishes CRLs. Is there a way to publish CRLs to file on Clone CA or I should sync /var/lib/pki/pki-tomcat/webapps/crl directory from Master CA? On Wed, Sep 2, 2015 at 10:17 PM, John Magne wrote: > Hi: > > I'm not sure what are try to accomplish. > The way we have it now, only the master publishes anywhere. > > > Is the concern over the internal OCSP of the cloned CA's > or are you publishing to some external OSCP responders? > If you are worried about the internal OCSP's of the clones, > they should give the correct answers about a given cert through > replication. > > If there is something else desired, let us know. > > thanks, > jack > > > > ----- Original Message ----- > > From: "Aleksey Chudov" > > To: pki-users at redhat.com > > Sent: Wednesday, September 2, 2015 5:04:59 AM > > Subject: [Pki-users] CRL to file publishing on Clone CA > > > > Hi, > > > > I have configured the same rules for CRL publishing on Master CA and two > > Clone CAs > > > > +ca.publish.enable=true > > +ca.publish.ldappublish.enable=false > > +ca.publish.publisher.instance.FileCrlPublisher.Filename.b64=false > > +ca.publish.publisher.instance.FileCrlPublisher.Filename.der=true > > +ca.publish.publisher.instance.FileCrlPublisher.crlLinkExt=crl > > > +ca.publish.publisher.instance.FileCrlPublisher.directory=/var/lib/pki/pki-tomcat/webapps/crl > > +ca.publish.publisher.instance.FileCrlPublisher.latestCrlLink=true > > > +ca.publish.publisher.instance.FileCrlPublisher.pluginName=FileBasedPublisher > > +ca.publish.publisher.instance.FileCrlPublisher.timeStamp=LocalTime > > +ca.publish.publisher.instance.FileCrlPublisher.zipCRLs=false > > +ca.publish.publisher.instance.FileCrlPublisher.zipLevel=9 > > +ca.publish.rule.instance.FileCrlRule.enable=true > > +ca.publish.rule.instance.FileCrlRule.mapper=NoMap > > +ca.publish.rule.instance.FileCrlRule.pluginName=Rule > > +ca.publish.rule.instance.FileCrlRule.predicate= > > +ca.publish.rule.instance.FileCrlRule.publisher=FileCrlPublisher > > +ca.publish.rule.instance.FileCrlRule.type=crl > > > > But only Master CA publishes CRLs to /var/lib/pki/pki-tomcat/webapps/crl > > directory. > > > > According to documentation > > > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/9/html/Planning_Installation_and_Deployment_Guide/Cloning_a_Subsystem.html#cloning-for-cas > > , only one replicated CA can generate, cache, and publish CRLs. > > > > What are the best practices of publishing CRLs on Clone CA? Should I just > > sync CRL directory on both clones from master, or is there a better > > approach? > > > > Aleksey > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Thu Sep 3 00:01:36 2015 From: jmagne at redhat.com (John Magne) Date: Wed, 2 Sep 2015 20:01:36 -0400 (EDT) Subject: [Pki-users] CRL to file publishing on Clone CA In-Reply-To: References: <1607308522.36937554.1441221477324.JavaMail.zimbra@redhat.com> Message-ID: <1161827292.37229359.1441238496046.JavaMail.zimbra@redhat.com> Oh I see: There are a couple of alternatives, but the way the server works right now is to only allow the Master to publish: 1. Publish to ldap instead? 2. Have some sort of file watcher on the master and push out updates to the other hosts maybe. ----- Original Message ----- > From: "Aleksey Chudov" > To: "John Magne" > Cc: pki-users at redhat.com > Sent: Wednesday, September 2, 2015 2:07:20 PM > Subject: Re: [Pki-users] CRL to file publishing on Clone CA > > To make it clear I have to tell a bit more about my CA scheme. > > I have three servers, Master CA + two Clone CAs. All three servers have > their own DNS names and also shared DNS name ca.local.mycompany.com. So, > ca.local.mycompany.com resolves to three ip addresses for load sharing and > high availability. > > All CA enrolled certificates contains extensions > > X509v3 CRL Distribution Points: > Full Name: > URI:http://ca.local.mycompany.com/crl/MasterCRL.crl > > Authority Information Access: > OCSP - URI:http://ca.local.mycompany.com > /ca/ocsp > > > > There is no problems with OCSP. It works out of the box. > > http://ca.local.mycompany.com/crl/ > URL internally points to > local directory on all three servers > > # grep -A1 crl /etc/pki/pki-tomcat/server.xml > docBase="/var/lib/pki/pki-tomcat/webapps/crl" > allowLinking="true"/> > > I need the CRL file to be available on all three servers for > http://ca.local.mycompany.com/crl/MasterCRL.crl URL to work. So, I have > configured CRL publishing to file in /var/lib/pki/pki-tomcat/webapps/crl > directory on all three servers. But only Master CA actually publishes CRLs. > > Is there a way to publish CRLs to file on Clone CA or I should sync > /var/lib/pki/pki-tomcat/webapps/crl directory from Master CA? > > > > > On Wed, Sep 2, 2015 at 10:17 PM, John Magne wrote: > > > Hi: > > > > I'm not sure what are try to accomplish. > > The way we have it now, only the master publishes anywhere. > > > > > > Is the concern over the internal OCSP of the cloned CA's > > or are you publishing to some external OSCP responders? > > If you are worried about the internal OCSP's of the clones, > > they should give the correct answers about a given cert through > > replication. > > > > If there is something else desired, let us know. > > > > thanks, > > jack > > > > > > > > ----- Original Message ----- > > > From: "Aleksey Chudov" > > > To: pki-users at redhat.com > > > Sent: Wednesday, September 2, 2015 5:04:59 AM > > > Subject: [Pki-users] CRL to file publishing on Clone CA > > > > > > Hi, > > > > > > I have configured the same rules for CRL publishing on Master CA and two > > > Clone CAs > > > > > > +ca.publish.enable=true > > > +ca.publish.ldappublish.enable=false > > > +ca.publish.publisher.instance.FileCrlPublisher.Filename.b64=false > > > +ca.publish.publisher.instance.FileCrlPublisher.Filename.der=true > > > +ca.publish.publisher.instance.FileCrlPublisher.crlLinkExt=crl > > > > > +ca.publish.publisher.instance.FileCrlPublisher.directory=/var/lib/pki/pki-tomcat/webapps/crl > > > +ca.publish.publisher.instance.FileCrlPublisher.latestCrlLink=true > > > > > +ca.publish.publisher.instance.FileCrlPublisher.pluginName=FileBasedPublisher > > > +ca.publish.publisher.instance.FileCrlPublisher.timeStamp=LocalTime > > > +ca.publish.publisher.instance.FileCrlPublisher.zipCRLs=false > > > +ca.publish.publisher.instance.FileCrlPublisher.zipLevel=9 > > > +ca.publish.rule.instance.FileCrlRule.enable=true > > > +ca.publish.rule.instance.FileCrlRule.mapper=NoMap > > > +ca.publish.rule.instance.FileCrlRule.pluginName=Rule > > > +ca.publish.rule.instance.FileCrlRule.predicate= > > > +ca.publish.rule.instance.FileCrlRule.publisher=FileCrlPublisher > > > +ca.publish.rule.instance.FileCrlRule.type=crl > > > > > > But only Master CA publishes CRLs to /var/lib/pki/pki-tomcat/webapps/crl > > > directory. > > > > > > According to documentation > > > > > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/9/html/Planning_Installation_and_Deployment_Guide/Cloning_a_Subsystem.html#cloning-for-cas > > > , only one replicated CA can generate, cache, and publish CRLs. > > > > > > What are the best practices of publishing CRLs on Clone CA? Should I just > > > sync CRL directory on both clones from master, or is there a better > > > approach? > > > > > > Aleksey > > > > > > _______________________________________________ > > > Pki-users mailing list > > > Pki-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-users > > > From aleksey.chudov at gmail.com Thu Sep 3 08:50:02 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Thu, 3 Sep 2015 11:50:02 +0300 Subject: [Pki-users] How to setup PKI CA to ask for passwords at startup? In-Reply-To: <55E7607B.6090502@redhat.com> References: <1440615963.23248.139.camel@redhat.com> <55E7607B.6090502@redhat.com> Message-ID: Certainly https://fedorahosted.org/pki/ticket/1602 On Wed, Sep 2, 2015 at 11:47 PM, Matthew Harmsen wrote: > Aleksey, > > Thanks for the instruction. > > Would you be willing to file a PKI TRAC Ticket on this: > > - https://fedorahosted.org/pki/newticket > > In general, we triage these tickets on a weekly basis, and assign it to an > appropriate release. > > For this specific ticket, although an actual fix may be a ways off, we > generally try to get this type of information documented as a workaround in > the near term. > > Thanks, > -- Matt > On 09/02/15 02:43, Aleksey Chudov wrote: > > Below is quick instruction of how to run > pki-tomcatd-nuxwdog at pki-tomcat.service as pkiuser:pkiuser in case it will > be useful for someone > > > systemctl stop pki-tomcatd-nuxwdog at pki-tomcat.service > > groupadd -r systemd-ask-password > > usermod -a -G systemd-ask-password pkiuser > > echo "d /run/systemd/ask-password 0775 root systemd-ask-password -" > > /etc/tmpfiles.d/systemd-ask-password.conf > > /usr/bin/systemd-tmpfiles --create systemd-ask-password.conf > > mkdir /etc/systemd/system/pki-tomcatd-nuxwdog at .service.d/ > > cat << EOF > /etc/systemd/system/pki-tomcatd-nuxwdog at .service.d/override.conf > > [Service] > User=pkiuser > Group=pkiuser > EOF > > systemctl daemon-reload > > find /var/lib/pki/ /var/log/pki/ /etc/pki/pki-*/ -exec chown > pkiuser:pkiuser {} + > > systemctl start pki-tomcatd-nuxwdog at pki-tomcat.service > > > > > On Wed, Sep 2, 2015 at 11:05 AM, Aleksey Chudov > wrote: > >> One big difference in starting PKI under nuxwdog control is that >> pki-tomcatd at pki-tomcat.service starts PKI as pkiuser:pkiuser but >> pki-tomcatd-nuxwdog at pki-tomcat.service starts PKI as root:root. Running >> PKI as root user is bad idea. >> >> >> >> >> On Thu, Aug 27, 2015 at 2:33 PM, Aleksey Chudov < >> aleksey.chudov at gmail.com> wrote: >> >>> To begin with I have updated to version 10.2.6 from F22 testing to get >>> pki-server man pages. >>> >>> Enabling nuxwdog solves the problem. Thank you! >>> >>> On Wed, Aug 26, 2015 at 10:06 PM, Ade Lee < >>> alee at redhat.com> wrote: >>> >>>> Aleksey, >>>> >>>> password prompting in CS 8.1 worked because of a utility program called >>>> nuxwdog which would prompt for passwords. >>>> >>>> We have done some work to get nuxwdog working with the latest Dogtag >>>> code, but there is some setup required. >>>> Fortunately, all that setup has been encapsulated in the pki-server >>>> utility. >>>> >>>> For details, man pki-server , man pki-server-instance and man >>>> pki-server-nuxwdog. >>>> >>>> The specific command would be: >>>> pki-server instance-nuxwdog-enable >>>> >>>> You should then be prompted for the passwords, and can remove your >>>> password.conf file. >>>> >>>> Ade >>>> On Wed, 2015-08-26 at 21:49 +0300, Aleksey Chudov wrote: >>>> >>>> I'm looking at removing at least nss password but both nss and 389 >>>> passwords will be better. >>>> >>>> Actually PKI prompts for password but I don't see the prompt because of >>>> systemd. >>>> >>>> To reproduce >>>> >>>> systemctl stop pki-tomcatd at pki-tomcat.service >>>> sed -i.bak '/internal=/d' /etc/pki/pki-tomcat/password.conf >>>> systemctl start pki-tomcatd at pki-tomcat.service >>>> >>>> /var/log/messages >>>> Aug 26 21:37:33 srv333 server[8889]: Enter password for Internal Key >>>> Storage Token >>>> >>>> /var/log/pki/pki-tomcat/ca/debug >>>> [26/Aug/2015:21:37:52][localhost-startStop-1]: Got token Internal Key >>>> Storage Token by name >>>> [26/Aug/2015:21:37:52][localhost-startStop-1]: SigningUnit init: debug >>>> org.mozilla.jss.util.IncorrectPasswordException >>>> Invalid Password >>>> at com.netscape.ca.SigningUnit.init(SigningUnit.java:192) >>>> at >>>> com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1229) >>>> at >>>> com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:342) >>>> at >>>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1107) >>>> at >>>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1013) >>>> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:520) >>>> at com.netscape.certsrv.apps.CMS.init(CMS.java:187) >>>> at com.netscape.certsrv.apps.CMS.start(CMS.java:1601) >>>> at >>>> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:114) >>>> at javax.servlet.GenericServlet.init(GenericServlet.java:158) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:606) >>>> at >>>> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277) >>>> at >>>> org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at javax.security.auth.Subject.doAsPrivileged(Subject.java:536) >>>> at >>>> org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309) >>>> at >>>> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169) >>>> at >>>> org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:123) >>>> at >>>> org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1272) >>>> at >>>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) >>>> at >>>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) >>>> at >>>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) >>>> at >>>> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) >>>> at >>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) >>>> at >>>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) >>>> at >>>> org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133) >>>> at >>>> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156) >>>> at >>>> org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) >>>> at java.security.AccessController.doPrivileged(Native Method) >>>> at >>>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) >>>> at >>>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) >>>> at >>>> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672) >>>> at >>>> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862) >>>> at >>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>>> at java.lang.Thread.run(Thread.java:745) >>>> [26/Aug/2015:21:37:52][localhost-startStop-1]: CMSEngine.shutdown() >>>> >>>> >>>> On Wed, Aug 26, 2015 at 8:09 PM, Dave Sirrine < >>>> dsirrine at redhat.com> wrote: >>>> >>>> Aleksey, >>>> >>>> Did removing the password from the file not cause the system to prompt >>>> you for the password at startup. Also, are you looking at doing both nss >>>> and 389 passwords? >>>> >>>> -- David >>>> On Aug 26, 2015 5:58 AM, "Aleksey Chudov" < >>>> aleksey.chudov at gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> The password.conf file stores system passwords in plaintext, and I >>>> prefer to enter system passwords manually and to remove the password file. >>>> >>>> I have found original documentation >>>> >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/System_Passwords.html. >>>> But it is for older version on PKI and does not work with systemd. >>>> >>>> How to setup PKI CA to ask for NSS DB password at startup? >>>> >>>> Packages versions (I have rebuilt F22 packages for CentOS 7): >>>> # rpm -qa | grep pki >>>> pki-base-10.2.5-1.el7.centos.noarch >>>> pki-server-10.2.5-1.el7.centos.noarch >>>> dogtag-pki-server-theme-10.2.5-1.el7.centos.noarch >>>> pki-ca-10.2.5-1.el7.centos.noarch >>>> pki-tools-10.2.5-1.el7.centos.x86_64 >>>> dogtag-pki-console-theme-10.2.5-1.el7.centos.noarch >>>> >>>> Aleksey >>>> >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.com >>>> >>>> https://www.redhat.com/mailman/listinfo/pki-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pki-users mailing listPki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users >>>> >>>> >>> >> > > > _______________________________________________ > Pki-users mailing listPki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.chudov at gmail.com Thu Sep 3 08:18:41 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Thu, 3 Sep 2015 11:18:41 +0300 Subject: [Pki-users] CRL to file publishing on Clone CA In-Reply-To: <1161827292.37229359.1441238496046.JavaMail.zimbra@redhat.com> References: <1607308522.36937554.1441221477324.JavaMail.zimbra@redhat.com> <1161827292.37229359.1441238496046.JavaMail.zimbra@redhat.com> Message-ID: Actually I do not like the idea of directory synchronization by using some third-party script. So, I found an alternative solution instead of publishing CRL to file. My PKI CA subsystem listen on default ports 8080 and 8443. And I use Apache mod_proxy for PKI CA to be available on standard ports 80 and 443. All I have to do is add a bit of Apache mod_rewrite magic: RewriteEngine on RewriteRule "^/crl/MasterCRL.crl$" "/ca/ee/ca/getCRL?crlIssuingPoint=MasterCRL&op=getCRL" [L,NC,PT] It works the same for the master and clones without the need of publishing. Thanks for your reminder of the availability of alternatives :) On Thu, Sep 3, 2015 at 3:01 AM, John Magne wrote: > Oh I see: > > There are a couple of alternatives, but the way the server works right now > is to only allow the Master to publish: > > 1. Publish to ldap instead? > > 2. Have some sort of file watcher on the master and push out updates to > the other hosts maybe. > > > > ----- Original Message ----- > > From: "Aleksey Chudov" > > To: "John Magne" > > Cc: pki-users at redhat.com > > Sent: Wednesday, September 2, 2015 2:07:20 PM > > Subject: Re: [Pki-users] CRL to file publishing on Clone CA > > > > To make it clear I have to tell a bit more about my CA scheme. > > > > I have three servers, Master CA + two Clone CAs. All three servers have > > their own DNS names and also shared DNS name ca.local.mycompany.com. So, > > ca.local.mycompany.com resolves to three ip addresses for load sharing > and > > high availability. > > > > All CA enrolled certificates contains extensions > > > > X509v3 CRL Distribution Points: > > Full Name: > > URI:http://ca.local.mycompany.com/crl/MasterCRL.crl > > > > Authority Information Access: > > OCSP - URI:http://ca.local.mycompany.com > > /ca/ocsp > > > > > > > > There is no problems with OCSP. It works out of the box. > > > > http://ca.local.mycompany.com/crl/ > > URL internally points > to > > local directory on all three servers > > > > # grep -A1 crl /etc/pki/pki-tomcat/server.xml > > > docBase="/var/lib/pki/pki-tomcat/webapps/crl" > > allowLinking="true"/> > > > > I need the CRL file to be available on all three servers for > > http://ca.local.mycompany.com/crl/MasterCRL.crl URL to work. So, I have > > configured CRL publishing to file in /var/lib/pki/pki-tomcat/webapps/crl > > directory on all three servers. But only Master CA actually publishes > CRLs. > > > > Is there a way to publish CRLs to file on Clone CA or I should sync > > /var/lib/pki/pki-tomcat/webapps/crl directory from Master CA? > > > > > > > > > > On Wed, Sep 2, 2015 at 10:17 PM, John Magne wrote: > > > > > Hi: > > > > > > I'm not sure what are try to accomplish. > > > The way we have it now, only the master publishes anywhere. > > > > > > > > > Is the concern over the internal OCSP of the cloned CA's > > > or are you publishing to some external OSCP responders? > > > If you are worried about the internal OCSP's of the clones, > > > they should give the correct answers about a given cert through > > > replication. > > > > > > If there is something else desired, let us know. > > > > > > thanks, > > > jack > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Aleksey Chudov" > > > > To: pki-users at redhat.com > > > > Sent: Wednesday, September 2, 2015 5:04:59 AM > > > > Subject: [Pki-users] CRL to file publishing on Clone CA > > > > > > > > Hi, > > > > > > > > I have configured the same rules for CRL publishing on Master CA and > two > > > > Clone CAs > > > > > > > > +ca.publish.enable=true > > > > +ca.publish.ldappublish.enable=false > > > > +ca.publish.publisher.instance.FileCrlPublisher.Filename.b64=false > > > > +ca.publish.publisher.instance.FileCrlPublisher.Filename.der=true > > > > +ca.publish.publisher.instance.FileCrlPublisher.crlLinkExt=crl > > > > > > > > +ca.publish.publisher.instance.FileCrlPublisher.directory=/var/lib/pki/pki-tomcat/webapps/crl > > > > +ca.publish.publisher.instance.FileCrlPublisher.latestCrlLink=true > > > > > > > > +ca.publish.publisher.instance.FileCrlPublisher.pluginName=FileBasedPublisher > > > > +ca.publish.publisher.instance.FileCrlPublisher.timeStamp=LocalTime > > > > +ca.publish.publisher.instance.FileCrlPublisher.zipCRLs=false > > > > +ca.publish.publisher.instance.FileCrlPublisher.zipLevel=9 > > > > +ca.publish.rule.instance.FileCrlRule.enable=true > > > > +ca.publish.rule.instance.FileCrlRule.mapper=NoMap > > > > +ca.publish.rule.instance.FileCrlRule.pluginName=Rule > > > > +ca.publish.rule.instance.FileCrlRule.predicate= > > > > +ca.publish.rule.instance.FileCrlRule.publisher=FileCrlPublisher > > > > +ca.publish.rule.instance.FileCrlRule.type=crl > > > > > > > > But only Master CA publishes CRLs to > /var/lib/pki/pki-tomcat/webapps/crl > > > > directory. > > > > > > > > According to documentation > > > > > > > > https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/9/html/Planning_Installation_and_Deployment_Guide/Cloning_a_Subsystem.html#cloning-for-cas > > > > , only one replicated CA can generate, cache, and publish CRLs. > > > > > > > > What are the best practices of publishing CRLs on Clone CA? Should I > just > > > > sync CRL directory on both clones from master, or is there a better > > > > approach? > > > > > > > > Aleksey > > > > > > > > _______________________________________________ > > > > Pki-users mailing list > > > > Pki-users at redhat.com > > > > https://www.redhat.com/mailman/listinfo/pki-users > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksey.chudov at gmail.com Mon Sep 7 12:03:03 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Mon, 7 Sep 2015 15:03:03 +0300 Subject: [Pki-users] This version of Firefox no longer supports the crypto web object... Message-ID: Hi, I use Firefox 40.0.3 from Fedora 21 updates repository $ rpm -q firefox firefox-40.0.3-1.fc21.x86_64 Every PKI CA certificate profile containing keyGenInputImpl input produces warning message on a web page: Warning: This version of Firefox no longer supports the crypto web object used to generate and archive keys from the browser. As a result expect limited functionality in this area. But actually key generation works in my Firefox version. What does this warning really mean? Aleksey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Tue Sep 8 03:23:41 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Tue, 8 Sep 2015 13:23:41 +1000 Subject: [Pki-users] This version of Firefox no longer supports the crypto web object... In-Reply-To: References: Message-ID: <20150908032341.GC17582@dhcp-40-8.bne.redhat.com> On Mon, Sep 07, 2015 at 03:03:03PM +0300, Aleksey Chudov wrote: > Hi, > > I use Firefox 40.0.3 from Fedora 21 updates repository > > $ rpm -q firefox > firefox-40.0.3-1.fc21.x86_64 > > Every PKI CA certificate profile containing keyGenInputImpl input produces > warning message on a web page: > > Warning: This version of Firefox no longer supports the crypto web object > used to generate and archive keys from the browser. As a result expect > limited functionality in this area. > > But actually key generation works in my Firefox version. > > What does this warning really mean? > It means that Firefox's API changed. The old, custom keygen / crypto API was deprecated for a long time, then removed, but the new, standardised Web Crypto API is not supported by Dogtag yet. Hope that clarifies the situation for you. Cheers, Fraser > Aleksey > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From aleksey.chudov at gmail.com Tue Sep 8 06:58:20 2015 From: aleksey.chudov at gmail.com (Aleksey Chudov) Date: Tue, 8 Sep 2015 09:58:20 +0300 Subject: [Pki-users] This version of Firefox no longer supports the crypto web object... In-Reply-To: <20150908032341.GC17582@dhcp-40-8.bne.redhat.com> References: <20150908032341.GC17582@dhcp-40-8.bne.redhat.com> Message-ID: Thank you for the clarification! Do you have a Track ticket on this issue? I can't find it. On Tue, Sep 8, 2015 at 6:23 AM, Fraser Tweedale wrote: > On Mon, Sep 07, 2015 at 03:03:03PM +0300, Aleksey Chudov wrote: > > Hi, > > > > I use Firefox 40.0.3 from Fedora 21 updates repository > > > > $ rpm -q firefox > > firefox-40.0.3-1.fc21.x86_64 > > > > Every PKI CA certificate profile containing keyGenInputImpl input > produces > > warning message on a web page: > > > > Warning: This version of Firefox no longer supports the crypto web object > > used to generate and archive keys from the browser. As a result expect > > limited functionality in this area. > > > > But actually key generation works in my Firefox version. > > > > What does this warning really mean? > > > It means that Firefox's API changed. The old, custom keygen / > crypto API was deprecated for a long time, then removed, but the > new, standardised Web Crypto API is not supported by Dogtag yet. > > Hope that clarifies the situation for you. > > Cheers, > Fraser > > > Aleksey > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Sep 14 04:05:43 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 14 Sep 2015 14:05:43 +1000 Subject: [Pki-users] This version of Firefox no longer supports the crypto web object... In-Reply-To: References: <20150908032341.GC17582@dhcp-40-8.bne.redhat.com> Message-ID: <20150914040543.GA16937@dhcp-40-8.bne.redhat.com> On Tue, Sep 08, 2015 at 09:58:20AM +0300, Aleksey Chudov wrote: > Thank you for the clarification! > > Do you have a Track ticket on this issue? I can't find it. > #1285 "generateCRMFRequest() removed from Firefox" [1] seems to cover it - specifically the option: (a) fix this profile Option: (b) supply a CLI for CRMF requests was probably addressed by #1074 "CLI for CRMF" [2]. [1] https://fedorahosted.org/pki/ticket/1285 [2] https://fedorahosted.org/pki/ticket/1074 Cheers, Fraser > > On Tue, Sep 8, 2015 at 6:23 AM, Fraser Tweedale wrote: > > > On Mon, Sep 07, 2015 at 03:03:03PM +0300, Aleksey Chudov wrote: > > > Hi, > > > > > > I use Firefox 40.0.3 from Fedora 21 updates repository > > > > > > $ rpm -q firefox > > > firefox-40.0.3-1.fc21.x86_64 > > > > > > Every PKI CA certificate profile containing keyGenInputImpl input > > produces > > > warning message on a web page: > > > > > > Warning: This version of Firefox no longer supports the crypto web object > > > used to generate and archive keys from the browser. As a result expect > > > limited functionality in this area. > > > > > > But actually key generation works in my Firefox version. > > > > > > What does this warning really mean? > > > > > It means that Firefox's API changed. The old, custom keygen / > > crypto API was deprecated for a long time, then removed, but the > > new, standardised Web Crypto API is not supported by Dogtag yet. > > > > Hope that clarifies the situation for you. > > > > Cheers, > > Fraser > > > > > Aleksey > > > > > _______________________________________________ > > > Pki-users mailing list > > > Pki-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/pki-users > > > > From Patrick.Raspante at gd-ms.com Thu Sep 17 16:27:32 2015 From: Patrick.Raspante at gd-ms.com (Raspante, Patrick) Date: Thu, 17 Sep 2015 16:27:32 +0000 Subject: [Pki-users] DirAclAuthz host configuration Message-ID: <84BD5400E758214492042CB7A25F842932C183EF@AZRC4SAZMSG14.rc4s.com> For the CA's authorization subsystem, Is it possible to configure the CA to look for users in a different DS instance than the one defined in 'internaldb.ldapconn.host' ? I've done some initial testing changing the following settings to point to another ds instance: authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.database= authz.instance.DirAclAuthz.ldap.ldapconn.host=myotherds authz.instance.DirAclAuthz.ldap.ldapconn.port=389 After a restart, the CA seems to still be doing authorization queries to the DS defined in 'internaldb.ldapconn.host'. Thanks, pwr -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Thu Sep 17 17:36:51 2015 From: msauton at redhat.com (Marc Sauton) Date: Thu, 17 Sep 2015 10:36:51 -0700 Subject: [Pki-users] DirAclAuthz host configuration In-Reply-To: <84BD5400E758214492042CB7A25F842932C183EF@AZRC4SAZMSG14.rc4s.com> References: <84BD5400E758214492042CB7A25F842932C183EF@AZRC4SAZMSG14.rc4s.com> Message-ID: <55FAFA33.300@redhat.com> On 09/17/2015 09:27 AM, Raspante, Patrick wrote: > > For the CA?s authorization subsystem, Is it possible to configure the > CA to look for users in a different DS instance than the one defined > in ?internaldb.ldapconn.host? ? > > I?ve done some initial testing changing the following settings to > point to another ds instance: > > authz.instance.DirAclAuthz.ldap.basedn= > authz.instance.DirAclAuthz.ldap.database= > > authz.instance.DirAclAuthz.ldap.ldapconn.host=myotherds > > authz.instance.DirAclAuthz.ldap.ldapconn.port=389 > > After a restart, the CA seems to still be doing authorization queries > to the DS defined in ?internaldb.ldapconn.host?. > > Thanks, > > pwr > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users you may define a separate authz authz.impl.myDirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz authz.instance.myDirAclAuthz.ldap.basedn= authz.instance.myDirAclAuthz.ldap.database= authz.instance.myDirAclAuthz.ldap.ldapconn.host=myotherds authz.instance.myDirAclAuthz.ldap.ldapconn.port=389 also add authz.instance.myDirAclAuthz.ldap=myotherdb and to enroll processor.caProfileSubmit.authzMgr=myDirAclAuthz M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patrick.Raspante at gd-ms.com Fri Sep 18 14:40:53 2015 From: Patrick.Raspante at gd-ms.com (Raspante, Patrick) Date: Fri, 18 Sep 2015 14:40:53 +0000 Subject: [Pki-users] DirAclAuthz host configuration In-Reply-To: <55FAFA33.300@redhat.com> References: <84BD5400E758214492042CB7A25F842932C183EF@AZRC4SAZMSG14.rc4s.com> <55FAFA33.300@redhat.com> Message-ID: <84BD5400E758214492042CB7A25F842932C184DE@AZRC4SAZMSG14.rc4s.com> Thanks Marc for the reply. As you suggested, I created myDirAclAuthz instance and used the 'myotherdb' ldap connection instance. When I start my CA, I see in the access log of 'myotherdb' that 'cn=aclResources' is searched for and returned successfully. Then if I authenticate to the CA Agent page, and exercise some operations (e.g. aclResource=certserver.ca.certificates Op=list), I see activity in the access log of the directory server defined in internaldb. No activity in the access log of 'myotherdb'. Is there a way to configure the CA's default authorization manager to look at myotherdb instead of the internaldb directory? pwr -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjaalton at ubuntu.com Mon Sep 21 21:38:19 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 22 Sep 2015 00:38:19 +0300 Subject: [Pki-users] build error with newer tomcat7, Debian issues Message-ID: <560078CB.4060603@ubuntu.com> Hi I'm not able to build 10.2.6 with a current tomcat7 (7.0.64): com/netscape/cms/tomcat/ProxyRealm.java:22: error: ProxyRealm is not abstract and does not override abstract method authenticate(String) in Realm public class ProxyRealm implements Realm { ^ 1 error which is what I need in order to debug if my switch to tomcat8 is to blame why the configure phase of a pki instance doesn't start on Debian: 2015-09-04 20:29:54 pkispawn : INFO ....... executing 'certutil -N -d /root/.dogtag/pki-tomcat/ca/alias -f /root/.dogtag/pki-tomcat/ca/password.conf' 2015-09-04 20:29:54 pkispawn : INFO ....... executing '/etc/init.d/pki-tomcatd start pki-tomcat' 2015-09-04 20:30:07 pkispawn : DEBUG ........... No connection - server may still be down 2015-09-04 20:30:07 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection a borted.', error(104, 'Connection reset by peer')) 2015-09-04 20:30:08 pkispawn : DEBUG ........... No connection - server may still be down 2015-09-04 20:30:08 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection a borted.', error(104, 'Connection reset by peer')) 2015-09-04 20:30:09 pkispawn : DEBUG ........... No connection - server may still be down 2015-09-04 20:30:09 pkispawn : DEBUG ........... No connection - exception thrown: ('Connection a borted.', error(104, 'Connection reset by peer')) 2015-09-04 20:30:10 pkispawn : DEBUG ........... No connection - server may still be down 2015-09-04 20:30:10 pkispawn : DEBUG ........... No connection - exception thrown: EOF occurred i n violation of protocol (_ssl.c:590) 2015-09-04 20:30:12 pkispawn : DEBUG ........... No connection - server may still be down 2015-09-04 20:30:12 pkispawn : DEBUG ........... No connection - exception thrown: EOF occurred i n violation of protocol (_ssl.c:590) ... .. . 2015-09-04 20:31:00 pkispawn : ERROR ....... server failed to restart 2015-09-04 20:31:00 pkispawn : DEBUG ....... Error Type: Exception 2015-09-04 20:31:00 pkispawn : DEBUG ....... Error Message: server failed to restart 2015-09-04 20:31:00 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 597, in main rv = instance.spawn(deployer) File "/usr/lib/python2.7/dist-packages/pki/server/deployment/scriptlets/configuration.py", line 102, in spawn raise Exception("server failed to restart") (don't have catalina output from this..) Another issue I found is that upgrading from 10.2.0 to 10.2.6 packages (w.tomcat8) gives these errors: http://pastebin.com/eM64FUDw so wonder if these are somehow related. -- t From tjaalton at ubuntu.com Tue Sep 22 22:29:56 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 23 Sep 2015 01:29:56 +0300 Subject: [Pki-users] build error with newer tomcat7, Debian issues In-Reply-To: <560078CB.4060603@ubuntu.com> References: <560078CB.4060603@ubuntu.com> Message-ID: <5601D664.5020505@ubuntu.com> On 22.09.2015 00:38, Timo Aaltonen wrote: > > Hi > > I'm not able to build 10.2.6 with a current tomcat7 (7.0.64): > > com/netscape/cms/tomcat/ProxyRealm.java:22: error: ProxyRealm is not > abstract and does not override abstract method authenticate(String) in Realm > public class ProxyRealm implements Realm { > ^ > 1 error So I got past this error with the help from IRC, and tomcat7-based packages of 10.2.6 seem to work fine for the most part. Need to look into the tomcat8 bits with greater detail, must've missed something. -- t From tjaalton at ubuntu.com Wed Sep 23 13:55:04 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 23 Sep 2015 16:55:04 +0300 Subject: [Pki-users] build error with newer tomcat7, Debian issues In-Reply-To: <5601D664.5020505@ubuntu.com> References: <560078CB.4060603@ubuntu.com> <5601D664.5020505@ubuntu.com> Message-ID: <5602AF38.3060506@ubuntu.com> On 23.09.2015 01:29, Timo Aaltonen wrote: > On 22.09.2015 00:38, Timo Aaltonen wrote: >> >> Hi >> >> I'm not able to build 10.2.6 with a current tomcat7 (7.0.64): >> >> com/netscape/cms/tomcat/ProxyRealm.java:22: error: ProxyRealm is not >> abstract and does not override abstract method authenticate(String) in Realm >> public class ProxyRealm implements Realm { >> ^ >> 1 error > > So I got past this error with the help from IRC, and tomcat7-based > packages of 10.2.6 seem to work fine for the most part. Need to look > into the tomcat8 bits with greater detail, must've missed something. So the failure with tomcat8 seems to boil down to not getting all the bits in CS.cfg, for instance: internaldb.ldapconn.host= internaldb.ldapconn.port= internaldb.ldapconn.secureConn=false which then results in this blurb from catalina.out: CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| tomcat7 version gets those right, and here's a diff from pki-ca-spawn log (- tomcat7, +tomcat8): @@ -1371,13 +1377,17 @@ pkispawn : DEBUG ........... slot substitution: '[PKI_HOSTNAME]' ==> 'sid-test.tyrell' pkispawn : DEBUG ........... slot substitution: '[TOMCAT_SERVER_PORT]' ==> '8005' pkispawn : DEBUG ........... slot substitution: '[TOMCAT_SERVER_PORT]' ==> '8005' +pkispawn : DEBUG ........... slot substitution: '[PKI_UNSECURE_PORT]' ==> '8080' pkispawn : DEBUG ........... slot substitution: '[PKI_UNSECURE_PORT_SERVER_COMMENT]' ==> '' pkispawn : DEBUG ........... slot substitution: '[PKI_INSTANCE_PATH]' ==> '/var/lib/pki/pki-tomcat' -pkispawn : DEBUG ........... slot substitution: '[PKI_INSTANCE_PATH]' ==> '/var/lib/pki/pki-tomcat' -pkispawn : DEBUG ........... slot substitution: '[PKI_INSTANCE_PATH]' ==> '/var/lib/pki/pki-tomcat' -pkispawn : DEBUG ........... slot substitution: '[PKI_INSTANCE_PATH]' ==> '/var/lib/pki/pki-tomcat' -pkispawn : DEBUG ........... slot substitution: '[PKI_INSTANCE_PATH]' ==> '/var/lib/pki/pki-tomcat' pkispawn : DEBUG ........... slot substitution: '[PKI_OPEN_TOMCAT_ACCESS_LOG_COMMENT]' ==> '' pkispawn : DEBUG ........... slot substitution: '[PKI_CLOSE_TOMCAT_ACCESS_LOG_COMMENT]' ==> '' pkispawn : DEBUG ........... chmod 660 /etc/pki/pki-tomcat/server.xml @@ -1417,7 +1423,6 @@ pkispawn : DEBUG ........... slot substitution: '[TOMCAT_PIDFILE]' ==> '/var/run/pki/tomcat/pki-tomc$ pkispawn : DEBUG ........... slot substitution: '[TOMCAT_LOG_DIR]' ==> '/var/log/pki/pki-tomcat' pkispawn : DEBUG ........... slot substitution: '[APPLICATION_VERSION]' ==> '10.2.6' -pkispawn : DEBUG ........... slot substitution: '[PKI_USER]' ==> 'pkiuser' pkispawn : DEBUG ........... slot substitution: '[PKI_SECURITY_MANAGER]' ==> 'false' pkispawn : DEBUG ........... chmod 660 /etc/default/pki-tomcat pkispawn : DEBUG ........... chown 0:0 /etc/default/pki-tomcat @@ -1431,7 +1436,6 @@ pkispawn : DEBUG ........... slot substitution: '[TOMCAT_PIDFILE]' ==> '/var/run/pki/tomcat/pki-tomc$ pkispawn : DEBUG ........... slot substitution: '[TOMCAT_LOG_DIR]' ==> '/var/log/pki/pki-tomcat' pkispawn : DEBUG ........... slot substitution: '[APPLICATION_VERSION]' ==> '10.2.6' -pkispawn : DEBUG ........... slot substitution: '[PKI_USER]' ==> 'pkiuser' pkispawn : DEBUG ........... slot substitution: '[PKI_SECURITY_MANAGER]' ==> 'false' pkispawn : DEBUG ........... chmod 660 /etc/pki/pki-tomcat/tomcat.conf pkispawn : DEBUG ........... chown 110:116 /etc/pki/pki-tomcat/tomcat.conf @@ -1474,7 +1478,7 @@ pkispawn : INFO ....... generating noise file called '/etc/pki/pki-tomcat/ca/noise' and filling it $ pkispawn : DEBUG ........... chmod 660 /etc/pki/pki-tomcat/ca/noise pkispawn : DEBUG ........... chown 110:116 /etc/pki/pki-tomcat/ca/noise -pkispawn : INFO ....... executing 'certutil -S -d /etc/pki/pki-tomcat/alias -h internal -n Server-C$ +pkispawn : INFO ....... executing 'certutil -S -d /etc/pki/pki-tomcat/alias -h internal -n Server-C$ pkispawn : INFO ....... rm -f /etc/pki/pki-tomcat/ca/noise pkispawn : INFO ....... rm -f /etc/pki/pki-tomcat/pfile pkispawn : INFO ....... ln -s /lib/systemd/system/pki-tomcatd at .service /etc/systemd/system/pki-tomc$ @@ -1496,590 +1500,113 @@ pkispawn : DEBUG ........... chown 0:0 /root/.dogtag/pki-tomcat/ca/alias pkispawn : INFO ....... executing 'certutil -N -d /root/.dogtag/pki-tomcat/ca/alias -f /root/.dogta$ pkispawn : INFO ....... executing '/etc/init.d/pki-tomcatd start pki-tomcat' -pkispawn : DEBUG ........... 0 Hi This is what I get in the logs when trying to install ipa server 4.1.4 on Debian: [21/27]: issuing RA agent certificate [error] CalledProcessError: Command ''/usr/bin/sslget' '-v' '-n' 'ipa-ca-agent' '-p' XXXXXXXX '-d' '/tmp/tmp-B_7AiF' '-r' '/ca/agent/ca/profileReview?requestId=7' 'sid-test.tyrell:8443'' returned non-zero exit status 3 Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command ''/usr/bin/sslget' '-v' '-n' 'ipa-ca-agent' '-p' XXXXXXXX '-d' '/tmp/tmp-B_7AiF' '-r' '/ca/agent/ca/profileReview?requestId=7' 'sid-test.tyrell:8443'' returned non-zero exit status 3 syys 24, 2015 7:33:21 AP. org.apache.catalina.core.ApplicationContext log SEVERE: Servlet castart threw unload() exception javax.servlet.ServletException: Servlet.destroy() for servlet castart threw exception at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1507) at org.apache.catalina.core.StandardWrapper.stopInternal(StandardWrapper.java:1847) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5700) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1590) at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1579) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at com.netscape.cmscore.profile.ProfileSubsystem.shutdown(ProfileSubsystem.java:226) at com.netscape.cmscore.apps.CMSEngine.shutdownSubsystems(CMSEngine.java:1859) at com.netscape.cmscore.apps.CMSEngine.shutdown(CMSEngine.java:1797) at com.netscape.certsrv.apps.CMS.shutdown(CMS.java:233) at com.netscape.cms.servlet.base.CMSStartServlet.destroy(CMSStartServlet.java:144) at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1486) ... 10 more syys 24, 2015 7:33:51 AP. org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [caProfileReview] in context with path [/ca] threw exception [Servlet execution threw an exception] with root cause java.lang.AbstractMethodError: org.apache.tomcat.util.net.jss.JSSSupport.getPeerCertificateChain(Z)[Ljava/lang/Object; at org.apache.coyote.http11.Http11Processor.actionInternal(Http11Processor.java:256) at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:911) at org.apache.coyote.Request.action(Request.java:347) at org.apache.catalina.connector.Request.getAttribute(Request.java:957) at org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:283) at com.netscape.cms.servlet.base.CMSServlet.getSSLClientCertificate(CMSServlet.java:858) at com.netscape.cms.servlet.base.CMSServlet.authenticate(CMSServlet.java:1743) at com.netscape.cms.servlet.base.CMSServlet.authenticate(CMSServlet.java:1685) at com.netscape.cms.servlet.profile.ProfileReviewServlet.process(ProfileReviewServlet.java:115) at com.netscape.cms.servlet.base.CMSServlet.service(CMSServlet.java:513) at javax.servlet.http.HttpServlet.service(HttpServlet.java:731) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) old packages of ipa 4.0.5 with 10.2.0 work -- t From tjaalton at ubuntu.com Thu Sep 24 05:58:20 2015 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 24 Sep 2015 08:58:20 +0300 Subject: [Pki-users] error installing ipa 4.1.4 w. pki 10.2.6 In-Reply-To: <56037FC5.1080609@ubuntu.com> References: <56037FC5.1080609@ubuntu.com> Message-ID: <560390FC.5010606@ubuntu.com> On 24.09.2015 07:44, Timo Aaltonen wrote: > > Hi > > This is what I get in the logs when trying to install ipa server 4.1.4 on Debian: now this was simple to fix.. tomcatjss was built against tomcat8, reverted back to building with tomcat7 and now it works again. -- t From wirelessben at gmail.com Thu Sep 24 12:36:06 2015 From: wirelessben at gmail.com (Ben Francis) Date: Thu, 24 Sep 2015 08:36:06 -0400 Subject: [Pki-users] Dogtag-pki Message-ID: Where is this package in EPEL 6 or EPEL 6 Testing? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.masson at jmips.co.uk Wed Sep 30 08:25:41 2015 From: james.masson at jmips.co.uk (James Masson) Date: Wed, 30 Sep 2015 09:25:41 +0100 Subject: [Pki-users] Flat-file auth Message-ID: <560B9C85.5090500@jmips.co.uk> Hi list, I'm trying to use flat-file auth on certificate requests via Certmonger. I can successfully get certificates issued when I remove authentication. I've restricted the Certificate Profile to require flat-file authentication. I'm running Centos7 with pki-server-10.1.2-7.el7.noarch and certmonger-0.78.4-1.el7.centos.x86_64 The error I get is. "[29/Sep/2015:15:31:38][http-bio-8080-exec-10]: CertProcessor: authentication error Authentication credential for uid is null. The request generated by Certmonger looks like this. ### GET /ca/ee/ca/profileSubmit?profileId=IPASubCA&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG%0ASIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q%0AnPQBQ6U0KbTKmKM81%2F2kD39eaMMzdyqBi%2BcbsPMOl93%2F%2FB88Eu8QRLis6hYMmgUF%0Av%2BcSS2JOHPOC8RY8YbkVlRYUGb%2BbMkldQEYsIOfad8xlfDBh%2Bg5ImA%2FrYS2g6MgV%0ACI0k%2F6w1nsNGJof7U2KEJpLJOvI%2F%2FwznaF%2FkuJC5kYrPLbOIEbQvM5%2F8Kcyh1W48%0AtgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67%2FAx%2FI2T34MpD5AN%0AWN1b9de3nWEce%2BMoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw%0AGwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG%0AA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX%2F%2BEWI84MCIG%0ACSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA%0AA4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T%2BkGSDgnzdK8afO8CwC6kfwAP8PZNo2L%0AcbpbiqYRSrwGOqmLpalxBG21T47c%2BonW2x8x4UYitpQH%2BUQE1P1SKiiiPA%2B6sj0f%0A5dFfPLjQGDrD1cpD! 8abY7HGPH 3 NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ%0APR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv%0AfKrckHp4AHK7B0hv%2FteB7GiqqrYA3cq9M3T6B17MnmjDF%2FyrS8uLl6DhFug0PLE2%0Afen%2FbDiCjJ3IDIqhS0hheym07ca8%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true&uid=foo&pwd=password ### flatfile.txt looks like: # uid:foo pwd:password # CS.cfg contains: # auths.instance.flatFileAuth.authAttributes=pwd auths.instance.flatFileAuth.deferOnFailure=true auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt auths.instance.flatFileAuth.keyAttributes=uid auths.instance.flatFileAuth.pluginName=FlatFileAuth # The full error from the pki debug logs is below thanks! James M ### [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet:service() uri = /ca/ee/ca/profileSubmit [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() param name='profileId' value='IPASubCA' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() param name='cert_request_type' value='pkcs10' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() param name='cert_request' value='-----BEGIN NEW CERTIFICATE REQUEST----- MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 fen/bDiCjJ3IDIqhS0hheym07ca8 -----END NEW CERTIFICATE REQUEST----- ' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() param name='xml' value='true' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() param name='uid' value='foo' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() param name='pwd' value='(sensitive)' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: caProfileSubmit start to service. [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: xmlOutput true [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: isRenewal false [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: according to ccMode, authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, use default authz mgr: {2}. [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: Start of CertProcessor Input Parameters [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input Parameter profileId='IPASubCA' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input Parameter cert_request_type='pkcs10' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input Parameter isRenewal='false' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input Parameter cert_request='-----BEGIN NEW CERTIFICATE REQUEST----- MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 fen/bDiCjJ3IDIqhS0hheym07ca8 -----END NEW CERTIFICATE REQUEST----- ' [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: End of CertProcessor Input Parameters [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: isRenewal false [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: profileId IPASubCA [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set Inputs into profile Context [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: authenticator flatFileAuth found [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertRequestSubmitter:setCredentialsIntoContext() authIds` null [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set sslClientCertProvider [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: authenticate: authentication required. [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: in auditSubjectID [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: auditSubjectID auditContext {sslClientCertProvider=com.netscape.cms.servlet.profile.SSLClientCertProvider at 5cd82562, profileContext=com.netscape.cms.profile.common.EnrollProfileContext at 727e748c} [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet auditSubjectID: subjectID: null [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: FlatFileAuth: concatenating string i=0 keyAttrs[0] = uid [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor: authentication error Authentication credential for uid is null. [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: SignedAuditEventFactory: create() message=[AuditEvent=AUTH_FAIL][SubjectID=$NonRoleUser$ : Unidentified][Outcome=Failure][AuthMgr=flatFileAuth][AttemptedCred=Unidentified] authentication failure [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: authentication error in processing request: Authentication credential for uid is null. [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: curDate=Wed Sep 30 08:14:32 UTC 2015 id=caProfileSubmit time=12 ### From jmagne at redhat.com Wed Sep 30 17:29:48 2015 From: jmagne at redhat.com (John Magne) Date: Wed, 30 Sep 2015 13:29:48 -0400 (EDT) Subject: [Pki-users] Flat-file auth In-Reply-To: <560B9C85.5090500@jmips.co.uk> References: <560B9C85.5090500@jmips.co.uk> Message-ID: <288197843.60568875.1443634188565.JavaMail.zimbra@redhat.com> Hi: Have you modified the cert profile you are using to point to that auth instance? See profiles/ca/caRouterCert.cfg for a sample. Hopefully that is your issue. ----- Original Message ----- > From: "James Masson" > To: pki-users at redhat.com > Sent: Wednesday, September 30, 2015 1:25:41 AM > Subject: [Pki-users] Flat-file auth > > > Hi list, > > I'm trying to use flat-file auth on certificate requests via Certmonger. > I can successfully get certificates issued when I remove authentication. > I've restricted the Certificate Profile to require flat-file authentication. > > I'm running Centos7 with pki-server-10.1.2-7.el7.noarch and > certmonger-0.78.4-1.el7.centos.x86_64 > > The error I get is. > > "[29/Sep/2015:15:31:38][http-bio-8080-exec-10]: CertProcessor: > authentication error Authentication credential for uid is null. > > The request generated by Certmonger looks like this. > > ### > GET > /ca/ee/ca/profileSubmit?profileId=IPASubCA&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG%0ASIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q%0AnPQBQ6U0KbTKmKM81%2F2kD39eaMMzdyqBi%2BcbsPMOl93%2F%2FB88Eu8QRLis6hYMmgUF%0Av%2BcSS2JOHPOC8RY8YbkVlRYUGb%2BbMkldQEYsIOfad8xlfDBh%2Bg5ImA%2FrYS2g6MgV%0ACI0k%2F6w1nsNGJof7U2KEJpLJOvI%2F%2FwznaF%2FkuJC5kYrPLbOIEbQvM5%2F8Kcyh1W48%0AtgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67%2FAx%2FI2T34MpD5AN%0AWN1b9de3nWEce%2BMoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw%0AGwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG%0AA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX%2F%2BEWI84MCIG%0ACSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA%0AA4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T%2BkGSDgnzdK8afO8CwC6kfwAP8PZNo2L%0AcbpbiqYRSrwGOqmLpalxBG21T47c%2BonW2x8x4UYitpQH%2BUQE1P1SKiiiPA%2B6sj0f%0A5dFfPLjQGDrD1cpD! > 8abY7HGPH > 3 > NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ%0APR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv%0AfKrckHp4AHK7B0hv%2FteB7GiqqrYA3cq9M3T6B17MnmjDF%2FyrS8uLl6DhFug0PLE2%0Afen%2FbDiCjJ3IDIqhS0hheym07ca8%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true&uid=foo&pwd=password > ### > > flatfile.txt looks like: > # > uid:foo > pwd:password > > > # > > CS.cfg contains: > # > auths.instance.flatFileAuth.authAttributes=pwd > auths.instance.flatFileAuth.deferOnFailure=true > auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt > auths.instance.flatFileAuth.keyAttributes=uid > auths.instance.flatFileAuth.pluginName=FlatFileAuth > # > > > The full error from the pki debug logs is below > > thanks! > > James M > > ### > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet:service() uri > = /ca/ee/ca/profileSubmit > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='profileId' value='IPASubCA' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='cert_request_type' value='pkcs10' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='cert_request' value='-----BEGIN NEW CERTIFICATE REQUEST----- > MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG > SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q > nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF > v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV > CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 > tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN > WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw > GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG > A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG > CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA > A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L > cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f > 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ > PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv > fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 > fen/bDiCjJ3IDIqhS0hheym07ca8 > -----END NEW CERTIFICATE REQUEST----- > ' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='xml' value='true' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='uid' value='foo' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='pwd' value='(sensitive)' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: > caProfileSubmit start to service. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: xmlOutput true > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: > isRenewal false > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: according to ccMode, > authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, > use default authz mgr: {2}. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: Start of CertProcessor > Input Parameters > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter profileId='IPASubCA' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter cert_request_type='pkcs10' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter isRenewal='false' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter cert_request='-----BEGIN NEW CERTIFICATE REQUEST----- > MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG > SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q > nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF > v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV > CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 > tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN > WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw > GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG > A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG > CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA > A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L > cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f > 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ > PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv > fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 > fen/bDiCjJ3IDIqhS0hheym07ca8 > -----END NEW CERTIFICATE REQUEST----- > ' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: End of CertProcessor > Input Parameters > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > isRenewal false > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > profileId IPASubCA > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set > Inputs into profile Context > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > authenticator flatFileAuth found > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: > CertRequestSubmitter:setCredentialsIntoContext() authIds` null > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set > sslClientCertProvider > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: authenticate: > authentication required. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: in auditSubjectID > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: > auditSubjectID auditContext > {sslClientCertProvider=com.netscape.cms.servlet.profile.SSLClientCertProvider at 5cd82562, > profileContext=com.netscape.cms.profile.common.EnrollProfileContext at 727e748c} > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet > auditSubjectID: subjectID: null > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: FlatFileAuth: > concatenating string i=0 keyAttrs[0] = uid > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor: > authentication error Authentication credential for uid is null. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: SignedAuditEventFactory: > create() message=[AuditEvent=AUTH_FAIL][SubjectID=$NonRoleUser$ : > Unidentified][Outcome=Failure][AuthMgr=flatFileAuth][AttemptedCred=Unidentified] > authentication failure > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: > authentication error in processing request: Authentication credential > for uid is null. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: curDate=Wed > Sep 30 08:14:32 UTC 2015 id=caProfileSubmit time=12 > ### > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From james.masson at jmips.co.uk Wed Sep 30 17:39:03 2015 From: james.masson at jmips.co.uk (James Masson) Date: Wed, 30 Sep 2015 18:39:03 +0100 Subject: [Pki-users] Flat-file auth In-Reply-To: <288197843.60568875.1443634188565.JavaMail.zimbra@redhat.com> References: <560B9C85.5090500@jmips.co.uk> <288197843.60568875.1443634188565.JavaMail.zimbra@redhat.com> Message-ID: CSR Profile does reference the flatFile provider. I've also tried the a similar setup with client-cert based auth, which also fails. Ditto with Dogtag 10.2 I must be missing something here, or else Certmonger's Dogtag auth options aren't doing what they should. Thanks James M On 30 Sep 2015 6:29 pm, "John Magne" wrote: > Hi: > > Have you modified the cert profile you are using to point to that auth > instance? > > See profiles/ca/caRouterCert.cfg for a sample. > > Hopefully that is your issue. > > > > ----- Original Message ----- > > From: "James Masson" > > To: pki-users at redhat.com > > Sent: Wednesday, September 30, 2015 1:25:41 AM > > Subject: [Pki-users] Flat-file auth > > > > > > Hi list, > > > > I'm trying to use flat-file auth on certificate requests via Certmonger. > > I can successfully get certificates issued when I remove authentication. > > I've restricted the Certificate Profile to require flat-file > authentication. > > > > I'm running Centos7 with pki-server-10.1.2-7.el7.noarch and > > certmonger-0.78.4-1.el7.centos.x86_64 > > > > The error I get is. > > > > "[29/Sep/2015:15:31:38][http-bio-8080-exec-10]: CertProcessor: > > authentication error Authentication credential for uid is null. > > > > The request generated by Certmonger looks like this. > > > > ### > > GET > > > /ca/ee/ca/profileSubmit?profileId=IPASubCA&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG%0ASIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q%0AnPQBQ6U0KbTKmKM81%2F2kD39eaMMzdyqBi%2BcbsPMOl93%2F%2FB88Eu8QRLis6hYMmgUF%0Av%2BcSS2JOHPOC8RY8YbkVlRYUGb%2BbMkldQEYsIOfad8xlfDBh%2Bg5ImA%2FrYS2g6MgV%0ACI0k%2F6w1nsNGJof7U2KEJpLJOvI%2F%2FwznaF%2FkuJC5kYrPLbOIEbQvM5%2F8Kcyh1W48%0AtgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67%2FAx%2FI2T34MpD5AN%0AWN1b9de3nWEce%2BMoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw%0AGwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG%0AA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX%2F%2BEWI84MCIG%0ACSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA%0AA4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T%2BkGSDgnzdK8afO8CwC6kfwAP8PZNo2L%0AcbpbiqYRSrwGOqmLpalxBG21T47c%2BonW2x8x4UYitpQH%2BUQE1P1SKiiiPA%2B6sj0f%0A5dFfPLjQGDrD1cpD! > > 8abY7HGPH > > 3 > > > NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ%0APR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv%0AfKrckHp4AHK7B0hv%2FteB7GiqqrYA3cq9M3T6B17MnmjDF%2FyrS8uLl6DhFug0PLE2%0Afen%2FbDiCjJ3IDIqhS0hheym07ca8%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true&uid=foo&pwd=password > > ### > > > > flatfile.txt looks like: > > # > > uid:foo > > pwd:password > > > > > > # > > > > CS.cfg contains: > > # > > auths.instance.flatFileAuth.authAttributes=pwd > > auths.instance.flatFileAuth.deferOnFailure=true > > > auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt > > auths.instance.flatFileAuth.keyAttributes=uid > > auths.instance.flatFileAuth.pluginName=FlatFileAuth > > # > > > > > > The full error from the pki debug logs is below > > > > thanks! > > > > James M > > > > ### > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet:service() uri > > = /ca/ee/ca/profileSubmit > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > > param name='profileId' value='IPASubCA' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > > param name='cert_request_type' value='pkcs10' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > > param name='cert_request' value='-----BEGIN NEW CERTIFICATE REQUEST----- > > MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG > > SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q > > nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF > > v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV > > CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 > > tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN > > WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw > > GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG > > A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG > > CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA > > A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L > > cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f > > 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ > > PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv > > fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 > > fen/bDiCjJ3IDIqhS0hheym07ca8 > > -----END NEW CERTIFICATE REQUEST----- > > ' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > > param name='xml' value='true' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > > param name='uid' value='foo' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > > param name='pwd' value='(sensitive)' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: > > caProfileSubmit start to service. > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: xmlOutput true > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: > > isRenewal false > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: according to ccMode, > > authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, > > use default authz mgr: {2}. > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: Start of CertProcessor > > Input Parameters > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > > Parameter profileId='IPASubCA' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > > Parameter cert_request_type='pkcs10' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > > Parameter isRenewal='false' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > > Parameter cert_request='-----BEGIN NEW CERTIFICATE REQUEST----- > > MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG > > SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q > > nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF > > v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV > > CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 > > tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN > > WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw > > GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG > > A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG > > CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA > > A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L > > cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f > > 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ > > PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv > > fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 > > fen/bDiCjJ3IDIqhS0hheym07ca8 > > -----END NEW CERTIFICATE REQUEST----- > > ' > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: End of CertProcessor > > Input Parameters > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > > isRenewal false > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > > profileId IPASubCA > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set > > Inputs into profile Context > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > > authenticator flatFileAuth found > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: > > CertRequestSubmitter:setCredentialsIntoContext() authIds` null > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set > > sslClientCertProvider > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: authenticate: > > authentication required. > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: in > auditSubjectID > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: > > auditSubjectID auditContext > > > {sslClientCertProvider=com.netscape.cms.servlet.profile.SSLClientCertProvider at 5cd82562 > , > > > profileContext=com.netscape.cms.profile.common.EnrollProfileContext at 727e748c > } > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet > > auditSubjectID: subjectID: null > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: FlatFileAuth: > > concatenating string i=0 keyAttrs[0] = uid > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor: > > authentication error Authentication credential for uid is null. > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: SignedAuditEventFactory: > > create() message=[AuditEvent=AUTH_FAIL][SubjectID=$NonRoleUser$ : > > > Unidentified][Outcome=Failure][AuthMgr=flatFileAuth][AttemptedCred=Unidentified] > > authentication failure > > > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: > > authentication error in processing request: Authentication credential > > for uid is null. > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: curDate=Wed > > Sep 30 08:14:32 UTC 2015 id=caProfileSubmit time=12 > > ### > > > > _______________________________________________ > > Pki-users mailing list > > Pki-users at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Sep 30 18:15:22 2015 From: jmagne at redhat.com (John Magne) Date: Wed, 30 Sep 2015 14:15:22 -0400 (EDT) Subject: [Pki-users] Flat-file auth In-Reply-To: References: <560B9C85.5090500@jmips.co.uk> <288197843.60568875.1443634188565.JavaMail.zimbra@redhat.com> Message-ID: <1322789142.60604033.1443636922031.JavaMail.zimbra@redhat.com> Looking at the code and your logs more closely. It looks like the proper auth manager is being invoked, and its reading the file correctly, it just appears that the UID and pwd are not making it to the back end. I can do some more poking around and get back. thanks, jack ----- Original Message ----- From: "James Masson" To: pki-users at redhat.com Sent: Wednesday, September 30, 2015 10:39:03 AM Subject: Re: [Pki-users] Flat-file auth CSR Profile does reference the flatFile provider. I've also tried the a similar setup with client-cert based auth, which also fails. Ditto with Dogtag 10.2 I must be missing something here, or else Certmonger's Dogtag auth options aren't doing what they should. Thanks James M On 30 Sep 2015 6:29 pm, "John Magne" < jmagne at redhat.com > wrote: Hi: Have you modified the cert profile you are using to point to that auth instance? See profiles/ca/caRouterCert.cfg for a sample. Hopefully that is your issue. ----- Original Message ----- > From: "James Masson" < james.masson at jmips.co.uk > > To: pki-users at redhat.com > Sent: Wednesday, September 30, 2015 1:25:41 AM > Subject: [Pki-users] Flat-file auth > > > Hi list, > > I'm trying to use flat-file auth on certificate requests via Certmonger. > I can successfully get certificates issued when I remove authentication. > I've restricted the Certificate Profile to require flat-file authentication. > > I'm running Centos7 with pki-server-10.1.2-7.el7.noarch and > certmonger-0.78.4-1.el7.centos.x86_64 > > The error I get is. > > "[29/Sep/2015:15:31:38][http-bio-8080-exec-10]: CertProcessor: > authentication error Authentication credential for uid is null. > > The request generated by Certmonger looks like this. > > ### > GET > /ca/ee/ca/profileSubmit?profileId=IPASubCA&cert_request_type=pkcs10&cert_request=-----BEGIN+NEW+CERTIFICATE+REQUEST-----%0AMIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG%0ASIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q%0AnPQBQ6U0KbTKmKM81%2F2kD39eaMMzdyqBi%2BcbsPMOl93%2F%2FB88Eu8QRLis6hYMmgUF%0Av%2BcSS2JOHPOC8RY8YbkVlRYUGb%2BbMkldQEYsIOfad8xlfDBh%2Bg5ImA%2FrYS2g6MgV%0ACI0k%2F6w1nsNGJof7U2KEJpLJOvI%2F%2FwznaF%2FkuJC5kYrPLbOIEbQvM5%2F8Kcyh1W48%0AtgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67%2FAx%2FI2T34MpD5AN%0AWN1b9de3nWEce%2BMoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw%0AGwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG%0AA1UdEwEB%2FwQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX%2F%2BEWI84MCIG%0ACSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA%0AA4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T%2BkGSDgnzdK8afO8CwC6kfwAP8PZNo2L%0AcbpbiqYRSrwGOqmLpalxBG21T47c%2BonW2x8x4UYitpQH%2BUQE1P1SKiiiPA%2B6sj0f%0A5dFfPLjQGDrD1cpD! > 8abY7HGPH > 3 > NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ%0APR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv%0AfKrckHp4AHK7B0hv%2FteB7GiqqrYA3cq9M3T6B17MnmjDF%2FyrS8uLl6DhFug0PLE2%0Afen%2FbDiCjJ3IDIqhS0hheym07ca8%0A-----END+NEW+CERTIFICATE+REQUEST-----%0A&xml=true&uid=foo&pwd=password > ### > > flatfile.txt looks like: > # > uid:foo > pwd:password > > > # > > CS.cfg contains: > # > auths.instance.flatFileAuth.authAttributes=pwd > auths.instance.flatFileAuth.deferOnFailure=true > auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt > auths.instance.flatFileAuth.keyAttributes=uid > auths.instance.flatFileAuth.pluginName=FlatFileAuth > # > > > The full error from the pki debug logs is below > > thanks! > > James M > > ### > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet:service() uri > = /ca/ee/ca/profileSubmit > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='profileId' value='IPASubCA' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='cert_request_type' value='pkcs10' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='cert_request' value='-----BEGIN NEW CERTIFICATE REQUEST----- > MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG > SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q > nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF > v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV > CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 > tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN > WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw > GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG > A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG > CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA > A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L > cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f > 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ > PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv > fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 > fen/bDiCjJ3IDIqhS0hheym07ca8 > -----END NEW CERTIFICATE REQUEST----- > ' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='xml' value='true' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='uid' value='foo' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet::service() > param name='pwd' value='(sensitive)' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: > caProfileSubmit start to service. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: xmlOutput true > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: > isRenewal false > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: according to ccMode, > authorization for servlet: caProfileSubmit is LDAP based, not XML {1}, > use default authz mgr: {2}. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: Start of CertProcessor > Input Parameters > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter profileId='IPASubCA' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter cert_request_type='pkcs10' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter isRenewal='false' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor Input > Parameter cert_request='-----BEGIN NEW CERTIFICATE REQUEST----- > MIIC4TCCAckCAQAwGTEXMBUGA1UEChMORk9PLlRFU1QuTkVXMjIwggEiMA0GCSqG > SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgDvLTtJB6lkQfN9XSu0LLwIdRE7A7Cb2q > nPQBQ6U0KbTKmKM81/2kD39eaMMzdyqBi+cbsPMOl93//B88Eu8QRLis6hYMmgUF > v+cSS2JOHPOC8RY8YbkVlRYUGb+bMkldQEYsIOfad8xlfDBh+g5ImA/rYS2g6MgV > CI0k/6w1nsNGJof7U2KEJpLJOvI//wznaF/kuJC5kYrPLbOIEbQvM5/8Kcyh1W48 > tgGks2vEZCZx3Ql3ZiOkFQKJ1d0S9zoeLJgAgpGjeU8RhMf67/Ax/I2T34MpD5AN > WN1b9de3nWEce+MoyiqvmxcIpOKfzTBEvlQFP7u2he9zD0ndSCm5AgMBAAGggYIw > GwYJKoZIhvcNAQkUMQ4eDAB0AGUAcwB0ADIAMjBjBgkqhkiG9w0BCQ4xVjBUMAwG > A1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFAT8lnV1XXyD4JKNwCooX/+EWI84MCIG > CSsGAQQBgjcUAgEBAAQSHhAASQBQAEEAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUA > A4IBAQB6MQffSUfOG8OvvlpTq1GU8vw9T+kGSDgnzdK8afO8CwC6kfwAP8PZNo2L > cbpbiqYRSrwGOqmLpalxBG21T47c+onW2x8x4UYitpQH+UQE1P1SKiiiPA+6sj0f > 5dFfPLjQGDrD1cpD8abY7HGPH3NikpvxXEsn6WpMc1hGFpFzHyQT8lviap3r8wSJ > PR4NVZLFBSqi1lcM72PQg6oIh9dHIiXo7aisPmQ4HqhPsBXhRICnuViFXGq0TDWv > fKrckHp4AHK7B0hv/teB7GiqqrYA3cq9M3T6B17MnmjDF/yrS8uLl6DhFug0PLE2 > fen/bDiCjJ3IDIqhS0hheym07ca8 > -----END NEW CERTIFICATE REQUEST----- > ' > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: End of CertProcessor > Input Parameters > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > isRenewal false > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > profileId IPASubCA > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set > Inputs into profile Context > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: > authenticator flatFileAuth found > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: > CertRequestSubmitter:setCredentialsIntoContext() authIds` null > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: EnrollmentSubmitter: set > sslClientCertProvider > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: authenticate: > authentication required. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: in auditSubjectID > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: > auditSubjectID auditContext > {sslClientCertProvider=com.netscape.cms.servlet.profile.SSLClientCertProvider at 5cd82562, > profileContext=com.netscape.cms.profile.common.EnrollProfileContext at 727e748c} > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet > auditSubjectID: subjectID: null > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: FlatFileAuth: > concatenating string i=0 keyAttrs[0] = uid > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CertProcessor: > authentication error Authentication credential for uid is null. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: SignedAuditEventFactory: > create() message=[AuditEvent=AUTH_FAIL][SubjectID=$NonRoleUser$ : > Unidentified][Outcome=Failure][AuthMgr=flatFileAuth][AttemptedCred=Unidentified] > authentication failure > > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: ProfileSubmitServlet: > authentication error in processing request: Authentication credential > for uid is null. > [30/Sep/2015:08:14:32][http-bio-8080-exec-24]: CMSServlet: curDate=Wed > Sep 30 08:14:32 UTC 2015 id=caProfileSubmit time=12 > ### > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From lachen at redhat.com Wed Sep 2 17:21:28 2015 From: lachen at redhat.com (Lan Chen) Date: Wed, 02 Sep 2015 17:21:28 -0000 Subject: [Pki-users] Dogtag 10.1 API In-Reply-To: Message-ID: <625987450.12482137.1441214487694.JavaMail.zimbra@redhat.com> Hi All, Is there good documentation on Dogtag 10.1 API somewhere? Lan ----- Original Message ----- From: "Ryan Murray" To: "Lan Chen" Sent: Wednesday, September 2, 2015 9:53:09 AM Subject: Re: Dogtag 10.1 There is a massive difference between the API's, I checked before raising the concern. By massive I mean they are all different. Example: 10.1 Noun=certs 10.2 Noun=certificates None of the other nouns are working as documented by 10.2. On Sep 2, 2015 9:50 AM, "Lan Chen" < lachen at redhat.com > wrote: Ryan, I just checked with Paul, we need it installed on RHEL. Could you see if the APIs documented for 10.2 also works for 10.1, there shouldn't be too big of a difference between the versions. From: "Ryan Murray" < rmurray at stonedoorgroup.com > To: "Lan Chen" < lachen at redhat.com > Sent: Wednesday, September 2, 2015 9:38:25 AM Subject: Re: Dogtag 10.1 The packages are not avaliable to the RHEL 7 channels or EPEL channels. From a technical standpoint I would need to spend time getting the exact limitations, but as it stands I would have to install tons of fedora packages or compile from source to get 10.2 running on RHEL. On Wednesday, September 2, 2015, Lan Chen < lachen at redhat.com > wrote:
I meant why can't 10.2 be on RHEL, and need to be on Fedora? From: "Ryan Murray" < rmurray at stonedoorgroup.com > To: "Lan Chen" < lachen at redhat.com > Sent: Wednesday, September 2, 2015 9:33:08 AM Subject: Re: Dogtag 10.1 There is no issue with the install, that was done Monday night. The issue is with the API not being documented. The client had to use fedora in all of their tests due to the newer 10.2 version and better API. On Wednesday, September 2, 2015, Lan Chen < lachen at redhat.com > wrote:
What's the issue on installing Dogtag 10.2 on RHEL? From: "Ryan Murray" < rmurray at stonedoorgroup.com > To: "Lan Chen" < lachen at redhat.com > Sent: Wednesday, September 2, 2015 8:02:27 AM Subject: Dogtag 10.1 Hi Lan, Could you please see if there is anyone at Red Hat technical that would have any documentation on the dog tag 10.1 API? It is not documented online that I can find. Hunting through source code to find undocumented API calls is a stretch on the SOW, and installing Fedora is a change to needs Red Hat's OK. Thanks
-------------- next part -------------- An HTML attachment was scrubbed... URL: From Patrick.Raspante at gd-ms.com Thu Sep 17 13:12:48 2015 From: Patrick.Raspante at gd-ms.com (Raspante, Patrick) Date: Thu, 17 Sep 2015 13:12:48 -0000 Subject: [Pki-users] DirAclAuthz host Message-ID: <84BD5400E758214492042CB7A25F842932C183AF@AZRC4SAZMSG14.rc4s.com> For the CA's authorization subsystem, Is it possible to configure the CA to look for users in a different DS instance than the one defined in 'internaldb.ldapconn.host' ? I've done some initial testing changing the following settings to point to another ds instance: authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.database= authz.instance.DirAclAuthz.ldap.ldapconn.host=myotherds authz.instance.DirAclAuthz.ldap.ldapconn.port=389 After a restart, the CA seems to still be doing authorization queries to the DS defined in 'internaldb.ldapconn.host'. Thanks, pwr -------------- next part -------------- An HTML attachment was scrubbed... URL: