From james.kinney at gtri.gatech.edu Fri Oct 1 19:04:50 2010 From: james.kinney at gtri.gatech.edu (James Kinney) Date: Fri, 1 Oct 2010 15:04:50 -0400 Subject: [Pki-users] how to use remote LDAP user auth with dogtag CA/RA? Message-ID: <1285959890.2008.6.camel@sis-jpk.stl.gtri.gatech.edu> I would like to use a remote ldap connection for user authentication at the CA for user certs. However, the ldap in use requires non-anonymous bind connections and the UidPwdDirAuth plugin does not provide for any connection type other than anonymous. There is a UidPwdPinDirAuth plugin that does provide binddn fields but that seems to not use them since the autotest that happens only returns an error from the server "connections failed. Anonymous connections not allowed" (or something similar). -- James "Jim" Kinney (404) 407-7967 GTRI -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2997 bytes Desc: not available URL: From jerry at cpmg.com Sun Oct 3 19:12:01 2010 From: jerry at cpmg.com (Jerry McCarthy) Date: Sun, 3 Oct 2010 12:12:01 -0700 Subject: [Pki-users] Rotating debug logs. Message-ID: <000001cb632e$dcc737c0$9655a740$@com> Some of my debug logs (/var/log/pki-*/debug) are getting large. I tried adding: /var/log/pki-ca/debug /var/log/pki-kra/debug /var/log/pki-ocsp/debug /var/log/pki-ra/debug { weekly rotate 5 notifempty missingok } To /etc/logrotate.d But that didn't appear to do anything. Can anybody give me some suggestions as to how to setup the debug logs for auto rotation? ? Regards, Jerry McCarthy CPMG ? From kchamart at redhat.com Wed Oct 6 15:11:04 2010 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 06 Oct 2010 20:41:04 +0530 Subject: [Pki-users] Rotating debug logs. In-Reply-To: <000001cb632e$dcc737c0$9655a740$@com> References: <000001cb632e$dcc737c0$9655a740$@com> Message-ID: <4CAC9188.4010105@redhat.com> On 10/04/2010 12:42 AM, Jerry McCarthy wrote: > Some of my debug logs (/var/log/pki-*/debug) are getting large. I tried > adding: > > /var/log/pki-ca/debug /var/log/pki-kra/debug /var/log/pki-ocsp/debug > /var/log/pki-ra/debug { > weekly > rotate 5 > notifempty > missingok > } > > To /etc/logrotate.d But that didn't appear to do anything. Can anybody give > me some suggestions as to how to setup the debug logs for auto rotation? I believe you can manipulate the 'maxFileSize' directive in /var/lib/pki-ca/conf/CS.cfg (similar for other subsystems) ------------------------- log.instance.SignedAudit.maxFileSize=2000 log.instance.System.maxFileSize=2000 log.instance.Transactions.maxFileSize=2000 ------------------------ If the file reaches a particular size limit, then the logs are rotated. If the vales in the above directives are increased, I think you'll see lesser rotation of logs. /kashyap > > > Regards, > > Jerry McCarthy > CPMG > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From jerry at cpmg.com Wed Oct 6 22:23:57 2010 From: jerry at cpmg.com (Jerry McCarthy) Date: Wed, 6 Oct 2010 15:23:57 -0700 Subject: [Pki-users] Rotating debug logs. In-Reply-To: <4CAC9188.4010105@redhat.com> References: <000001cb632e$dcc737c0$9655a740$@com> <4CAC9188.4010105@redhat.com> Message-ID: <000001cb65a5$2bcb15d0$83614170$@com> I can see where the SignedAudit System and Transactions logs have log.instance type settings but I am interested in the debug log. It does not appear to have the same controls on the CS.cfg file. My SignedAudit System and Transactions logs are already rotating fine. Are you saying that if I add a: log.instance.debug.maxFileSize=2000 ? to the appropriate CS.cfg my debug logs will rotate? Regards, Jerry McCarthy CPMG ? -----Original Message----- From: Kashyap Chamarthy [mailto:kchamart at redhat.com] Sent: Wednesday, October 06, 2010 8:11 AM To: Jerry McCarthy Cc: pki-users at redhat.com Subject: Re: [Pki-users] Rotating debug logs. On 10/04/2010 12:42 AM, Jerry McCarthy wrote: > Some of my debug logs (/var/log/pki-*/debug) are getting large. I tried > adding: > > /var/log/pki-ca/debug /var/log/pki-kra/debug /var/log/pki-ocsp/debug > /var/log/pki-ra/debug { > weekly > rotate 5 > notifempty > missingok > } > > To /etc/logrotate.d But that didn't appear to do anything. Can anybody give > me some suggestions as to how to setup the debug logs for auto rotation? I believe you can manipulate the 'maxFileSize' directive in /var/lib/pki-ca/conf/CS.cfg (similar for other subsystems) ------------------------- log.instance.SignedAudit.maxFileSize=2000 log.instance.System.maxFileSize=2000 log.instance.Transactions.maxFileSize=2000 ------------------------ If the file reaches a particular size limit, then the logs are rotated. If the vales in the above directives are increased, I think you'll see lesser rotation of logs. /kashyap > > > Regards, > > Jerry McCarthy > CPMG > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From kchamart at redhat.com Fri Oct 8 09:26:29 2010 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 08 Oct 2010 14:56:29 +0530 Subject: [Pki-users] Rotating debug logs. In-Reply-To: <000001cb65a5$2bcb15d0$83614170$@com> References: <000001cb632e$dcc737c0$9655a740$@com> <4CAC9188.4010105@redhat.com> <000001cb65a5$2bcb15d0$83614170$@com> Message-ID: <4CAEE3C5.9070202@redhat.com> On 10/07/2010 03:53 AM, Jerry McCarthy wrote: > I can see where the SignedAudit System and Transactions logs have > log.instance type settings but I am interested in the debug log. It does > not appear to have the same controls on the CS.cfg file. My SignedAudit > System and Transactions logs are already rotating fine. Are you saying that > if I add a: > > log.instance.debug.maxFileSize=2000 I don't think this is possible to do as of yet. > > to the appropriate CS.cfg my debug logs will rotate? > > Regards, > > Jerry McCarthy > CPMG > > > -----Original Message----- > From: Kashyap Chamarthy [mailto:kchamart at redhat.com] > Sent: Wednesday, October 06, 2010 8:11 AM > To: Jerry McCarthy > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] Rotating debug logs. > > On 10/04/2010 12:42 AM, Jerry McCarthy wrote: >> Some of my debug logs (/var/log/pki-*/debug) are getting large. I tried >> adding: >> >> /var/log/pki-ca/debug /var/log/pki-kra/debug /var/log/pki-ocsp/debug >> /var/log/pki-ra/debug { >> weekly >> rotate 5 >> notifempty >> missingok >> } >> >> To /etc/logrotate.d But that didn't appear to do anything. Can anybody > give >> me some suggestions as to how to setup the debug logs for auto rotation? > > I believe you can manipulate the 'maxFileSize' directive in > /var/lib/pki-ca/conf/CS.cfg > (similar for other subsystems) > ------------------------- > log.instance.SignedAudit.maxFileSize=2000 > log.instance.System.maxFileSize=2000 > log.instance.Transactions.maxFileSize=2000 > ------------------------ > > If the file reaches a particular size limit, then the logs are rotated. If > the vales in > the above directives are increased, I think you'll see lesser rotation of > logs. > > > > /kashyap > >> >> >> Regards, >> >> Jerry McCarthy >> CPMG >> >> >> >> >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > > From fdh at x-zone.org Sun Oct 10 09:41:08 2010 From: fdh at x-zone.org (Frederic d'Huart) Date: Sun, 10 Oct 2010 11:41:08 +0200 Subject: [Pki-users] PKI Console - Publishing Acl Error Message-ID: <4CB18A34.5030908@x-zone.org> Hello Pki Users, I have an problem to access the DogTAG Publishing tab of the PKIConsole. I want to enable a new CRL File publishing object as described into the section 8.2.1 of the admin guide. but I receive the error "You are not allowed to perform this operation" anytime I'm trying to access the publishing tab and subObjects. The ca_log show this error ___ /var/log/pki-ca/debug [10/Oct/2010:11:06:52][http-9445-Processor24]: LdapBoundConnFactory.java:391:returnConn() returnConn: mNumConns now 3 [10/Oct/2010:11:06:52][http-9445-Processor24]: AAclAuthz.java:643:evaluateExpressions() evaluated expression: group="Registration Manager Agents" to be true [10/Oct/2010:11:06:52][http-9445-Processor24]: SignedAuditEventFactory.java:78:create() SignedAuditEventFactory: create() message=[AuditEvent=AUTHZ_FAIL][SubjectID=admin][Outcome=Failure][aclResource=][Op=] authorization failure [10/Oct/2010:11:06:52][http-9445-Processor24]: LdapBoundConnFactory.java:343:getConn() getConn: mNumConns now 2 [10/Oct/2010:11:06:52][http-9445-Processor24]: LdapBoundConnFactory.java:391:returnConn() returnConn: mNumConns now 3 [10/Oct/2010:11:06:52][http-9445-Processor24]: SignedAuditEventFactory.java:78:create() SignedAuditEventFactory: create() message=[AuditEvent=ROLE_ASSUME][SubjectID=admin][Outcome=Failure][Role=Certificate Manager Agents, Registration Manager Agents, Trusted Managers, Administrators, Security Domain Administrators, Enterprise CA Administrators, Enterprise KRA Administrators, Enterprise OCSP Administrators, Enterprise TKS Administrators, Enterprise RA Administrators, Enterprise TPS Administrators] assume privileged role I have checked everywhere in the PKIConsole ACL's tab, but I didn't find anything ... Does somebody would have an idea how to fix it ? Thank you .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Thu Oct 14 18:32:42 2010 From: alee at redhat.com (Ade Lee) Date: Thu, 14 Oct 2010 14:32:42 -0400 Subject: [Pki-users] PKI Console - Publishing Acl Error In-Reply-To: <4CB18A34.5030908@x-zone.org> References: <4CB18A34.5030908@x-zone.org> Message-ID: <1287081162.8778.42.camel@localhost.localdomain> This bug has been fixed in the latest versions. See https://bugzilla.redhat.com/show_bug.cgi?id=621602 for details. Basically, there is a typo (one too many ||) in the acl entry: certServer.publisher.configuration You can fix this in the acl.ldif file or even through the acl configuration in the pkiconsole. Ade On Sun, 2010-10-10 at 11:41 +0200, Frederic d'Huart wrote: > Hello Pki Users, > > I have an problem to access the DogTAG Publishing tab of the > PKIConsole. > > I want to enable a new CRL File publishing object as described into > the section 8.2.1 of the admin guide. > but I receive the error "You are not allowed to perform this > operation" anytime I'm trying to access the > publishing tab and subObjects. > > The ca_log show this error > ___ > > /var/log/pki-ca/debug > > [10/Oct/2010:11:06:52][http-9445-Processor24]: > LdapBoundConnFactory.java:391:returnConn() returnConn: mNumConns now 3 > [10/Oct/2010:11:06:52][http-9445-Processor24]: > AAclAuthz.java:643:evaluateExpressions() evaluated expression: > group="Registration Manager Agents" to be true > [10/Oct/2010:11:06:52][http-9445-Processor24]: > SignedAuditEventFactory.java:78:create() SignedAuditEventFactory: > create() > message=[AuditEvent=AUTHZ_FAIL][SubjectID=admin][Outcome=Failure][aclResource=][Op=] authorization failure > > [10/Oct/2010:11:06:52][http-9445-Processor24]: > LdapBoundConnFactory.java:343:getConn() getConn: mNumConns now 2 > [10/Oct/2010:11:06:52][http-9445-Processor24]: > LdapBoundConnFactory.java:391:returnConn() returnConn: mNumConns now 3 > [10/Oct/2010:11:06:52][http-9445-Processor24]: > SignedAuditEventFactory.java:78:create() SignedAuditEventFactory: > create() > message=[AuditEvent=ROLE_ASSUME][SubjectID=admin][Outcome=Failure][Role=Certificate Manager Agents, Registration Manager Agents, Trusted Managers, Administrators, Security Domain Administrators, Enterprise CA Administrators, Enterprise KRA Administrators, Enterprise OCSP Administrators, Enterprise TKS Administrators, Enterprise RA Administrators, Enterprise TPS Administrators] assume privileged role > > > I have checked everywhere in the PKIConsole ACL's tab, but I didn't > find anything ... > Does somebody would have an idea how to fix it ? > > > > Thank you .. > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users From fdh at x-zone.org Fri Oct 15 08:49:35 2010 From: fdh at x-zone.org (Frederic d'Huart) Date: Fri, 15 Oct 2010 10:49:35 +0200 Subject: [Pki-users] PKI Console - Publishing Acl Error In-Reply-To: <1287081162.8778.42.camel@localhost.localdomain> References: <4CB18A34.5030908@x-zone.org> <1287081162.8778.42.camel@localhost.localdomain> Message-ID: <4CB8159F.6020907@x-zone.org> Ade, Thank you very much it works now :) -- Frederic On 10/14/2010 08:32 PM, Ade Lee wrote: > This bug has been fixed in the latest versions. See > https://bugzilla.redhat.com/show_bug.cgi?id=621602 for details. > > Basically, there is a typo (one too many ||) in the acl entry: > certServer.publisher.configuration > > You can fix this in the acl.ldif file or even through the acl > configuration in the pkiconsole. > > Ade > > On Sun, 2010-10-10 at 11:41 +0200, Frederic d'Huart wrote: > >> Hello Pki Users, >> >> I have an problem to access the DogTAG Publishing tab of the >> PKIConsole. >> >> I want to enable a new CRL File publishing object as described into >> the section 8.2.1 of the admin guide. >> but I receive the error "You are not allowed to perform this >> operation" anytime I'm trying to access the >> publishing tab and subObjects. >> >> The ca_log show this error >> ___ >> >> /var/log/pki-ca/debug >> >> [10/Oct/2010:11:06:52][http-9445-Processor24]: >> LdapBoundConnFactory.java:391:returnConn() returnConn: mNumConns now 3 >> [10/Oct/2010:11:06:52][http-9445-Processor24]: >> AAclAuthz.java:643:evaluateExpressions() evaluated expression: >> group="Registration Manager Agents" to be true >> [10/Oct/2010:11:06:52][http-9445-Processor24]: >> SignedAuditEventFactory.java:78:create() SignedAuditEventFactory: >> create() >> message=[AuditEvent=AUTHZ_FAIL][SubjectID=admin][Outcome=Failure][aclResource=][Op=] authorization failure >> >> [10/Oct/2010:11:06:52][http-9445-Processor24]: >> LdapBoundConnFactory.java:343:getConn() getConn: mNumConns now 2 >> [10/Oct/2010:11:06:52][http-9445-Processor24]: >> LdapBoundConnFactory.java:391:returnConn() returnConn: mNumConns now 3 >> [10/Oct/2010:11:06:52][http-9445-Processor24]: >> SignedAuditEventFactory.java:78:create() SignedAuditEventFactory: >> create() >> message=[AuditEvent=ROLE_ASSUME][SubjectID=admin][Outcome=Failure][Role=Certificate Manager Agents, Registration Manager Agents, Trusted Managers, Administrators, Security Domain Administrators, Enterprise CA Administrators, Enterprise KRA Administrators, Enterprise OCSP Administrators, Enterprise TKS Administrators, Enterprise RA Administrators, Enterprise TPS Administrators] assume privileged role >> >> >> I have checked everywhere in the PKIConsole ACL's tab, but I didn't >> find anything ... >> Does somebody would have an idea how to fix it ? >> >> >> >> Thank you .. >> _______________________________________________ >> Pki-users mailing list >> Pki-users at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-users >> > From jerry at cpmg.com Sun Oct 17 18:26:07 2010 From: jerry at cpmg.com (Jerry McCarthy) Date: Sun, 17 Oct 2010 11:26:07 -0700 Subject: [Pki-users] Rotating debug logs. Message-ID: <000001cb6e28$c4c76460$4e562d20$@com> Replying to my own post for others edification. I changed the logrotate to: /var/log/pki-ca/debug /var/log/pki-kra/debug /var/log/pki-ocsp/debug /var/log/pki-ra/debug { copytruncate weekly rotate 5 notifempty missingok } And now my logs are rotating fine. Regards, Jerry McCarthy CPMG -----Original Message----- From: Jerry McCarthy [mailto:jerry at cpmg.com] Sent: Sunday, October 03, 2010 12:12 PM To: 'pki-users at redhat.com' Subject: Rotating debug logs. Some of my debug logs (/var/log/pki-*/debug) are getting large. I tried adding: /var/log/pki-ca/debug /var/log/pki-kra/debug /var/log/pki-ocsp/debug /var/log/pki-ra/debug { weekly rotate 5 notifempty missingok } To /etc/logrotate.d But that didn't appear to do anything. Can anybody give me some suggestions as to how to setup the debug logs for auto rotation? ? Regards, Jerry McCarthy CPMG ? From Thomas.Peter2 at swisscom.com Wed Oct 20 12:35:10 2010 From: Thomas.Peter2 at swisscom.com (Thomas.Peter2 at swisscom.com) Date: Wed, 20 Oct 2010 14:35:10 +0200 Subject: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? Message-ID: <4527A721F8118C4C98E4B79EF84DF78905727573F0@sg000036.corproot.net> Hi! Can anybody help me with the following question: Is it possible to use the Auto Enrollment Proxy for Windows (AEP) with a Dogtag CA? More precisely: I setup a Dogtag Certification Authority on a computer running Fedora 13. It works fine through the webinterface that is provided with the Dogtag Sertificate System. I also setup AEP according to all the instructions found here. I'm pretty sure that I did all the configurations needed in my Windows domain and the corresponding Active Directory. When I request a certificate from the domain controller (I request a certificate of the type 'Domain Controller', as described here), I can capture a fair amount of TCP traffic (with Wireshark) between the domain controller and the computer that is running the Dogtag CA on the correct port (default 9445). However, my Dogtag CA seems to reject the certificate signing requests (CSR) it receives from my Windows domain controller, the domain controller issues the error message "The certificate request cannot be created. The requested property value is empty". I know this error message does not really state what I observe, why would there be traffic on the wire, if the CSR has not even been created (Windows...). If I request a certificate from the command line, as described here, I get the error message "The parameter is incorrect. 0x80070057 (WIN32: 87)". I did not do any special AEP related configuration on my Dogtag CA, as this page seems to be incomplete. Do I need to configure my Dogtag CA in any way for this to work or wouldn't it work at all (because a Dogtag CA might not really be a Red Hat Certificate System CA)? Thank you for your help! Thomas Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Wed Oct 20 16:46:29 2010 From: jmagne at redhat.com (Jack Magne) Date: Wed, 20 Oct 2010 09:46:29 -0700 Subject: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? In-Reply-To: <4527A721F8118C4C98E4B79EF84DF78905727573F0@sg000036.corproot.net> References: <4527A721F8118C4C98E4B79EF84DF78905727573F0@sg000036.corproot.net> Message-ID: <4CBF1CE5.5040408@redhat.com> On 10/20/2010 05:35 AM, Thomas.Peter2 at swisscom.com wrote: > Hi! > Can anybody help me with the following question: > Is it possible to use the _Auto Enrollment Proxy for Windows_ > > (AEP) with a Dogtag CA? > More precisely: > I setup a _Dogtag Certification Authority_ > on a computer > running Fedora 13. It works fine through the webinterface that is > provided with the Dogtag Sertificate System. I also setup AEP > according to all the instructions found _here_ > . > I'm pretty sure that I did all the configurations needed in my Windows > domain and the corresponding Active Directory. When I request a > certificate from the domain controller (I request a certificate of the > type 'Domain Controller', as described _here_ > ), > I can capture a fair amount of TCP traffic (with Wireshark) between > the domain controller and the computer that is running the Dogtag CA > on the correct port (default 9445). However, my Dogtag CA seems to > reject the certificate signing requests (CSR) it receives from my > Windows domain controller, the domain controller issues the error > message "The certificate request cannot be created. The requested > property value is empty". I know this error message does not really > state what I observe, why would there be traffic on the wire, if the > CSR has not even been created (Windows...). If I request a certificate > from the command line, as described _here_ > , I > get the error message "The parameter is incorrect. 0x80070057 (WIN32: > 87)". > I did not do any special AEP related configuration on my Dogtag CA, as > _this_ > page > seems to be incomplete. > Do I need to configure my Dogtag CA in any way for this to work or > wouldn't it work at all (because a Dogtag CA might not really be a Red > Hat Certificate System CA)? > Thank you for your help! > Thomas Peter > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > Hi: Are you getting anything from the CA's logs when this request is issued? Located in /var/lib/pki-ca/logs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thomas.Peter2 at swisscom.com Thu Oct 21 08:43:45 2010 From: Thomas.Peter2 at swisscom.com (Thomas.Peter2 at swisscom.com) Date: Thu, 21 Oct 2010 10:43:45 +0200 Subject: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? In-Reply-To: <4CBF1CE5.5040408@redhat.com> References: <4527A721F8118C4C98E4B79EF84DF78905727573F0@sg000036.corproot.net> <4CBF1CE5.5040408@redhat.com> Message-ID: <4527A721F8118C4C98E4B79EF84DF78905727F7401@sg000036.corproot.net> Hi Jack! Thank you for your response! I didn't even know about those log files, thanks for the hint. And yes, I'm getting something there. Everytime I do (exatly) this or the command line part described here, I get a line like the following in the logfile "/var/lib/pki-ca/log/localhost_access_log.2010-10-21.txt" on my Dogtag CA host: 192.168.1.10 - - [21/Oct/2010:10:26:48 +0200] "POST /ca/ee/ca/profileSubmitSSLClient HTTP/1.1" 404 5765 Obviously something is not right (404!), but what? The address 192.168.1.10 is the address of my domain controller. I also attached the wireshark trace that produced the line above to this mail (192.168.1.13 is the IP address of my Dogtag CA host). Do you (or anybody) have an idea what might be going on? Thank you! Thomas From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Jack Magne Sent: Wednesday, October 20, 2010 6:46 PM To: pki-users at redhat.com Subject: Re: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? On 10/20/2010 05:35 AM, Thomas.Peter2 at swisscom.com wrote: Hi! Can anybody help me with the following question: Is it possible to use the Auto Enrollment Proxy for Windows (AEP) with a Dogtag CA? More precisely: I setup a Dogtag Certification Authority on a computer running Fedora 13. It works fine through the webinterface that is provided with the Dogtag Sertificate System. I also setup AEP according to all the instructions found here. I'm pretty sure that I did all the configurations needed in my Windows domain and the corresponding Active Directory. When I request a certificate from the domain controller (I request a certificate of the type 'Domain Controller', as described here), I can capture a fair amount of TCP traffic (with Wireshark) between the domain controller and the computer that is running the Dogtag CA on the correct port (default 9445). However, my Dogtag CA seems to reject the certificate signing requests (CSR) it receives from my Windows domain controller, the domain controller issues the error message "The certificate request cannot be created. The requested property value is empty". I know this error message does not really state what I observe, why would there be traffic on the wire, if the CSR has not even been created (Windows...). If I request a certificate from the command line, as described here, I get the error message "The parameter is incorrect. 0x80070057 (WIN32: 87)". I did not do any special AEP related configuration on my Dogtag CA, as this page seems to be incomplete. Do I need to configure my Dogtag CA in any way for this to work or wouldn't it work at all (because a Dogtag CA might not really be a Red Hat Certificate System CA)? Thank you for your help! Thomas Peter _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users Hi: Are you getting anything from the CA's logs when this request is issued? Located in /var/lib/pki-ca/logs. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: domain_cert_request.pcap Type: application/octet-stream Size: 11716 bytes Desc: domain_cert_request.pcap URL: From Thomas.Peter2 at swisscom.com Thu Oct 21 08:54:21 2010 From: Thomas.Peter2 at swisscom.com (Thomas.Peter2 at swisscom.com) Date: Thu, 21 Oct 2010 10:54:21 +0200 Subject: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? References: <4527A721F8118C4C98E4B79EF84DF78905727573F0@sg000036.corproot.net> <4CBF1CE5.5040408@redhat.com> Message-ID: <4527A721F8118C4C98E4B79EF84DF78905727F743A@sg000036.corproot.net> RESOLVED! YAY! Ha! Guess what I found in the logfile "debug" in the same directory: "Use HTTPS port '9444' instead of '9445' when performing EE tasks!". Lol, it was that easy. Works like a charm now! Thanks for the hint to the log files again! Greets Thomas From: Peter Thomas, SCS-HR-RCU-UMT Sent: Thursday, October 21, 2010 10:44 AM To: 'pki-users at redhat.com' Subject: RE: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? Hi Jack! Thank you for your response! I didn't even know about those log files, thanks for the hint. And yes, I'm getting something there. Everytime I do (exatly) this or the command line part described here, I get a line like the following in the logfile "/var/lib/pki-ca/log/localhost_access_log.2010-10-21.txt" on my Dogtag CA host: 192.168.1.10 - - [21/Oct/2010:10:26:48 +0200] "POST /ca/ee/ca/profileSubmitSSLClient HTTP/1.1" 404 5765 Obviously something is not right (404!), but what? The address 192.168.1.10 is the address of my domain controller. I also attached the wireshark trace that produced the line above to this mail (192.168.1.13 is the IP address of my Dogtag CA host). Do you (or anybody) have an idea what might be going on? Thank you! Thomas From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Jack Magne Sent: Wednesday, October 20, 2010 6:46 PM To: pki-users at redhat.com Subject: Re: [Pki-users] Auto Enrollment Proxy for Windows with Dogtag CA? On 10/20/2010 05:35 AM, Thomas.Peter2 at swisscom.com wrote: Hi! Can anybody help me with the following question: Is it possible to use the Auto Enrollment Proxy for Windows (AEP) with a Dogtag CA? More precisely: I setup a Dogtag Certification Authority on a computer running Fedora 13. It works fine through the webinterface that is provided with the Dogtag Sertificate System. I also setup AEP according to all the instructions found here. I'm pretty sure that I did all the configurations needed in my Windows domain and the corresponding Active Directory. When I request a certificate from the domain controller (I request a certificate of the type 'Domain Controller', as described here), I can capture a fair amount of TCP traffic (with Wireshark) between the domain controller and the computer that is running the Dogtag CA on the correct port (default 9445). However, my Dogtag CA seems to reject the certificate signing requests (CSR) it receives from my Windows domain controller, the domain controller issues the error message "The certificate request cannot be created. The requested property value is empty". I know this error message does not really state what I observe, why would there be traffic on the wire, if the CSR has not even been created (Windows...). If I request a certificate from the command line, as described here, I get the error message "The parameter is incorrect. 0x80070057 (WIN32: 87)". I did not do any special AEP related configuration on my Dogtag CA, as this page seems to be incomplete. Do I need to configure my Dogtag CA in any way for this to work or wouldn't it work at all (because a Dogtag CA might not really be a Red Hat Certificate System CA)? Thank you for your help! Thomas Peter _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users Hi: Are you getting anything from the CA's logs when this request is issued? Located in /var/lib/pki-ca/logs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdh at x-zone.org Fri Oct 22 09:56:28 2010 From: fdh at x-zone.org (Frederic d'Huart) Date: Fri, 22 Oct 2010 11:56:28 +0200 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error Message-ID: <4CC15FCC.6030903@x-zone.org> Hello Pki users, Section B.1.4. of the RH admin guide refers to the following acceptable values for crlDistributionPoint Type: DirectoryName URIName RelativeToIssuer Using PKIConsole, I have added to the caUserCert profile a policy for include a CDP as follow: policyset.userCertSet.13.default.name=CRL Distribution Points Extension Default policyset.userCertSet.13.default.params.crlDistPointsCritical=false policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http://xxx.xxx.xxx/crl/xxx.crl policyset.userCertSet.13.default.params.crlDistPointsReasons_0= after profile re-activated, and new request generated, I get the following error on the agent interface: The Certificate System has encountered an unrecoverable error. Error Message: /java.lang.ClassCastException: netscape.security.x509.Extension cannot be cast to netscape.security.x509.CRLDistributionPointsExtension/ Please contact your local administrator for assistance. Any Ideas what could be wrong ? Thank you. From sean.veale at gdc4s.com Fri Oct 22 13:14:02 2010 From: sean.veale at gdc4s.com (sean.veale at gdc4s.com) Date: Fri, 22 Oct 2010 09:14:02 -0400 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error In-Reply-To: <4CC15FCC.6030903@x-zone.org> References: <4CC15FCC.6030903@x-zone.org> Message-ID: <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> Hi, Usually there is a reference to a Impl classID so the CA knows what to function/class to call when generating this part of the cert. For my system (built on Redhat CS 8.0 instead of dogtag but those codebases are very similar) I have this in my cert profiles and it generates the Crl dp entry in the cert without errors. policyset.userCertSet.13.constraint.class_id=noConstraintImpl policyset.userCertSet.13constraint.name=No Constraint policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul tImpl policyset.userCertSet.13.default.name=CRL Distribution Points Extension Default policyset.userCertSet.13.default.params.crlDistPointsCritical=false policyset.userCertSet.13.default.params.crlDistPointsNum=1 policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// xxx.xxx.xxx/crl/xxx.crl I don't believe you need to specify the No Constraint fields, as I just have them in there if later I wanted to enforce a specific CRL distribution point, it would require less updates to the profile. This line here is the one I think you need. policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul tImpl As it tells the CA what class to call into when generating this part of the cert. I don't think this is needed either, but it was in the example certs from the CS 8.0 install so I left it. policyset.userCertSet.13.default.params.crlDistPointsNum=1 I presume it is just letting the CA know after you added one CRL to the cert you can move on but I have dug into the code to find out. Sean This message and/or attachments may include information subject to GDC4S O.M. 1.8.6 and GD Corporate Policy 07-105 and are intended to be accessed only by authorized recipients. Use, storage and transmission are governed by General Dynamics and its policies. Contractual restrictions apply to third parties. Recipients should refer to the policies or contract to determine proper handling. Unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender and destroy all copies of the original message. -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Frederic d'Huart Sent: Friday, October 22, 2010 5:56 AM To: pki-users at redhat.com Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error Hello Pki users, Section B.1.4. of the RH admin guide refers to the following acceptable values for crlDistributionPoint Type: DirectoryName URIName RelativeToIssuer Using PKIConsole, I have added to the caUserCert profile a policy for include a CDP as follow: policyset.userCertSet.13.default.name=CRL Distribution Points Extension Default policyset.userCertSet.13.default.params.crlDistPointsCritical=false policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// xxx.xxx.xxx/crl/xxx.crl policyset.userCertSet.13.default.params.crlDistPointsReasons_0= after profile re-activated, and new request generated, I get the following error on the agent interface: The Certificate System has encountered an unrecoverable error. Error Message: /java.lang.ClassCastException: netscape.security.x509.Extension cannot be cast to netscape.security.x509.CRLDistributionPointsExtension/ Please contact your local administrator for assistance. Any Ideas what could be wrong ? Thank you. _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From fdh at x-zone.org Wed Oct 27 21:19:44 2010 From: fdh at x-zone.org (Frederic d'Huart) Date: Wed, 27 Oct 2010 23:19:44 +0200 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error In-Reply-To: <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> Message-ID: <4CC89770.1050504@x-zone.org> Thank you Very much Sean for your answer, and sorry for my late answer. In fact : policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul tImpl was already enabled ... In fact the Java Error occur when I enable policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName If I remove the URIName or If I replace it with any other possible values, I don't get this error any more. May I ask you which Java and Os Version are you using on your system ? I'm Using FC12 and OpenJDK Runtime Environment (IcedTea6 1.8.1) (fedora-40.b18.fc12-i386) OpenJDK Client VM (build 14.0-b16, mixed mode) Thank you. Kind Regards. On 10/22/2010 03:14 PM, sean.veale at gdc4s.com wrote: > Hi, Usually there is a reference to a Impl classID so the CA knows what > to function/class to call when generating this part of the cert. > > For my system (built on Redhat CS 8.0 instead of dogtag but those > codebases are very similar) I have this in my cert profiles and it > generates the Crl dp entry in the cert without errors. > > policyset.userCertSet.13.constraint.class_id=noConstraintImpl > policyset.userCertSet.13constraint.name=No Constraint > policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul > tImpl > policyset.userCertSet.13.default.name=CRL Distribution Points Extension > Default > policyset.userCertSet.13.default.params.crlDistPointsCritical=false > policyset.userCertSet.13.default.params.crlDistPointsNum=1 > policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// > xxx.xxx.xxx/crl/xxx.crl > > > I don't believe you need to specify the No Constraint fields, as I just > have them in there if later I wanted to enforce a specific CRL > distribution point, it would require less updates to the profile. > > This line here is the one I think you need. > policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul > tImpl > > As it tells the CA what class to call into when generating this part of > the cert. > > I don't think this is needed either, but it was in the example certs > from the CS 8.0 install so I left it. > policyset.userCertSet.13.default.params.crlDistPointsNum=1 > > I presume it is just letting the CA know after you added one CRL to the > cert you can move on but I have dug into the code to find out. > > Sean > > > This message and/or attachments may include information subject to GDC4S > O.M. 1.8.6 and GD Corporate Policy 07-105 and are intended to be > accessed only by authorized recipients. Use, storage and transmission > are governed by General Dynamics and its policies. Contractual > restrictions apply to third parties. Recipients should refer to the > policies or contract to determine proper handling. Unauthorized review, > use, disclosure or distribution is prohibited. If you are not an > intended recipient, please contact the sender and destroy all copies of > the original message. > > > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] > On Behalf Of Frederic d'Huart > Sent: Friday, October 22, 2010 5:56 AM > To: pki-users at redhat.com > Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: > Type_0 : URIName error > > Hello Pki users, > > > Section B.1.4. of the RH admin guide refers to the following acceptable > values > for crlDistributionPoint Type: > > DirectoryName > URIName > RelativeToIssuer > > > > Using PKIConsole, I have added to the caUserCert profile a policy for > include a CDP as follow: > > policyset.userCertSet.13.default.name=CRL Distribution Points Extension > Default > policyset.userCertSet.13.default.params.crlDistPointsCritical=false > policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName > policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// > xxx.xxx.xxx/crl/xxx.crl > policyset.userCertSet.13.default.params.crlDistPointsReasons_0= > > after profile re-activated, and new request generated, I get the > following error on the agent interface: > > The Certificate System has encountered an unrecoverable error. > > Error Message: > /java.lang.ClassCastException: netscape.security.x509.Extension cannot > be cast to netscape.security.x509.CRLDistributionPointsExtension/ > > Please contact your local administrator for assistance. > > > Any Ideas what could be wrong ? > > > Thank you. > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From sean.veale at gdc4s.com Fri Oct 29 13:20:35 2010 From: sean.veale at gdc4s.com (sean.veale at gdc4s.com) Date: Fri, 29 Oct 2010 09:20:35 -0400 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error In-Reply-To: <4CC89770.1050504@x-zone.org> References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> <4CC89770.1050504@x-zone.org> Message-ID: <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> Hi I'm using RH Enterprise Linux 5.3 Java -version gives Java Version "1.6.0.0" OpenJDK Runtime Environment (IcedTea6 1.6) (rhel-1.11.b16.el5-x86_64) OpenJDK 64 Bit Server VM (build 14.0-b16, mixed mode) Looks like I'm running a slightly older version of the OpenJDK vm, and I'm on a 64 bit platform instead of the 32 bit one you are on. A red-hat rep would have to weigh in if either would be significant in this case. Sean On 10/22/2010 03:14 PM, sean.veale at gdc4s.com wrote: > Hi, Usually there is a reference to a Impl classID so the CA knows what > to function/class to call when generating this part of the cert. > > For my system (built on Redhat CS 8.0 instead of dogtag but those > codebases are very similar) I have this in my cert profiles and it > generates the Crl dp entry in the cert without errors. > > policyset.userCertSet.13.constraint.class_id=noConstraintImpl > policyset.userCertSet.13constraint.name=No Constraint > policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul > tImpl > policyset.userCertSet.13.default.name=CRL Distribution Points Extension > Default > policyset.userCertSet.13.default.params.crlDistPointsCritical=false > policyset.userCertSet.13.default.params.crlDistPointsNum=1 > policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// > xxx.xxx.xxx/crl/xxx.crl > > > I don't believe you need to specify the No Constraint fields, as I just > have them in there if later I wanted to enforce a specific CRL > distribution point, it would require less updates to the profile. > > This line here is the one I think you need. > policyset.userCertSet.13.default.class_id=crlDistributionPointsExtDefaul > tImpl > > As it tells the CA what class to call into when generating this part of > the cert. > > I don't think this is needed either, but it was in the example certs > from the CS 8.0 install so I left it. > policyset.userCertSet.13.default.params.crlDistPointsNum=1 > > I presume it is just letting the CA know after you added one CRL to the > cert you can move on but I have dug into the code to find out. > > Sean > > > This message and/or attachments may include information subject to GDC4S > O.M. 1.8.6 and GD Corporate Policy 07-105 and are intended to be > accessed only by authorized recipients. Use, storage and transmission > are governed by General Dynamics and its policies. Contractual > restrictions apply to third parties. Recipients should refer to the > policies or contract to determine proper handling. Unauthorized review, > use, disclosure or distribution is prohibited. If you are not an > intended recipient, please contact the sender and destroy all copies of > the original message. > > > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] > On Behalf Of Frederic d'Huart > Sent: Friday, October 22, 2010 5:56 AM > To: pki-users at redhat.com > Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: > Type_0 : URIName error > > Hello Pki users, > > > Section B.1.4. of the RH admin guide refers to the following acceptable > values > for crlDistributionPoint Type: > > DirectoryName > URIName > RelativeToIssuer > > > > Using PKIConsole, I have added to the caUserCert profile a policy for > include a CDP as follow: > > policyset.userCertSet.13.default.name=CRL Distribution Points Extension > Default > policyset.userCertSet.13.default.params.crlDistPointsCritical=false > policyset.userCertSet.13.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.13.default.params.crlDistPointsPointType_0=URIName > policyset.userCertSet.13.default.params.crlDistPointsPointName_0=http:// > xxx.xxx.xxx/crl/xxx.crl > policyset.userCertSet.13.default.params.crlDistPointsReasons_0= > > after profile re-activated, and new request generated, I get the > following error on the agent interface: > > The Certificate System has encountered an unrecoverable error. > > Error Message: > /java.lang.ClassCastException: netscape.security.x509.Extension cannot > be cast to netscape.security.x509.CRLDistributionPointsExtension/ > > Please contact your local administrator for assistance. > > > Any Ideas what could be wrong ? > > > Thank you. > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users >