From techpkiuser at gmail.com Mon Oct 1 05:13:23 2012 From: techpkiuser at gmail.com (pki tech) Date: Mon, 1 Oct 2012 10:43:23 +0530 Subject: [Pki-users] DogTag CS for CentOS or later Fedora Versions In-Reply-To: <506455A6.5020109@redhat.com> References: <506455A6.5020109@redhat.com> Message-ID: John, Thanks. Had a quick look at the project. Seems nice and will dig deep. On Thu, Sep 27, 2012 at 7:03 PM, John Dennis wrote: > On 09/27/2012 04:24 AM, pki tech wrote: > >> Hi all, >> >> Im planning to go for a Large scale CA implementation with Current >> DogTag release 9.0 on Fedora 15. But the main worry that i have is the >> Fedora Support Cycle, which makes an doubt on the security of the >> Systems at the long run. >> >> Are there anyone who has successfully deployed a complete CA, OCSP and >> RA based solution on CentOS platform? If so I can continue my >> implementations with CentOS. What I found while googling was there are >> package issues while deploying DogTag over CentOS. >> >> Although the main site says DogTag 9.0 is tested for up to only Fedora >> 15, I found rpms for the subsystems pki-ca, pki-ocsp and pki-ra in other >> Fedora repositories for example Fedora 16. So will it be possible to >> have a stable PKI infrastructure over Fedora 16 with DogTag 9.0 (DogTag >> 10 is still in alpha stage) >> >> In the meantime I'm locally testing all the functionalities of DogTag >> 9.0 over Fedora 16 and CentOS. Will update as I progress. >> > > The IPA project (www.freeipa.org) uses dogtag as a core component of it's > infrastructure. On Fedora IPA is known as freeipa and on RHEL (CentOS is a > RHEL clone) it's known as just ipa. IPA is a critical component of many new > deployments (RHEL, Fedora, and hopefully soon others) and since dogtag > heavily is used by IPA you can be assured it's getting a lot attention and > will run well on our targeted distributions (especially RHEL and it's > derivatives). > > I'm not sure what you plan to use dogtag for, but IPA may give a much > friendlier way to access the functionality found in dogtag, as well as a > host of other features. > > The packaging issues you refer to are likely solved now largely because > when IPA started making heavy use of dogtag a few years ago those issues > percolated to the top and were addressed. The dogtag and IPA teams work > very closely together and are constantly refining both products, you > shouldn't worry in this regard. > > HTH, > > John > > > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From techpkiuser at gmail.com Mon Oct 1 05:29:41 2012 From: techpkiuser at gmail.com (pki tech) Date: Mon, 1 Oct 2012 10:59:41 +0530 Subject: [Pki-users] Server Error at RA installation Message-ID: Hi Experts, I'm stuck with an RA installation with Fedora DogTag 9.0 over Fedora 15. I got my root CA and CA instances working fine. Then I started installing the RA. As it progresses, I was prompted to enter the security domain. So I set the security domain URL and certificate chain was loaded. As I pressed next, I got this error as the response. ---------------------------------------------------------------------------------------------------- Internal Server Error ------------------------ The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, you example com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. ---------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------- pki-ra error log --------------------------- [Sun Sep 30 23:23:25 2012] [info] Subsequent (No.18) HTTPS request received for child 10 (server ra.example.com:12890) GET /ca/admin/ca/getDomainXML HTTP/1.0 port: 9445 addr='ca.example.com' family='2' -- SSL3: Server Certificate Validated. PR_Write wrote 42 bytes from bigBuf bytes: [GET /ca/admin/ca/getDomainXML HTTP/1.0 ] do_writes shutting down send socket do_writes exiting with (failure = 0) connection 1 read 252 bytes (252 total). these bytes read: connection 1 read 252 bytes total. ----------------------------- [Sun Sep 30 23:23:25 2012] [error] [client 192.168.3.203] Could not find httpd.xml in /usr/sbin/ at /var/lib/pki-ra/lib/perl/PKI/RA/DisplayCertChainPanel.pm line 228\n, referer: https://ra.example.com:12890/ra/admin/console/config/wizard [Sun Sep 30 23:23:25 2012] [info] Connection to child 10 closed (server ra.iris.lk:12890, client 192.168.3.203) ---------------------------------------------------------------------------------------------------------------------------- I Tried reinstalling the RA instance, but got the same result. Highly Appreciated If some expert could help me on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Mon Oct 1 05:45:59 2012 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 01 Oct 2012 11:15:59 +0530 Subject: [Pki-users] Server Error at RA installation In-Reply-To: References: Message-ID: <50692E17.4000503@redhat.com> On 10/01/2012 10:59 AM, pki tech wrote: > Hi Experts, > > I'm stuck with an RA installation with Fedora DogTag 9.0 over Fedora 15. You seem to be using an out of support Fedora release. Hi, the current supported Fedora releases are F16(this will go out of support very soon, once F18 releases, which is on its way) and F17. Dogtag has been revamped a lot lately. So please try with latest Fedora and Dogtag10. That said, I'm afraid, I haven't seen the below error last time when I configured RA on Fedora. It's unlikely you'll get much help till you're able to reproduce this issue with latest Dogtag bits on latest Fedora. -- /kashyap > > I got my root CA and CA instances working fine. Then I started installing the RA. As it > progresses, I was prompted to enter the security domain. So I set the security domain URL > and certificate chain was loaded. As I pressed next, I got this error as the response. > > ---------------------------------------------------------------------------------------------------- > Internal Server Error > ------------------------ > The server encountered an internal error or misconfiguration and was unable to complete > your request. > > Please contact the server administrator, you example com and inform them of the time the > error occurred, and anything you might have done that may have caused the error. > > More information about this error may be available in the server error log. > ---------------------------------------------------------------------------------------------------- > > ---------------------------------------------------------------------------------------------------- > pki-ra error log > --------------------------- > > [Sun Sep 30 23:23:25 2012] [info] Subsequent (No.18) HTTPS request received for child 10 > (server ra.example.com:12890 ) > GET /ca/admin/ca/getDomainXML HTTP/1.0 > > port: 9445 > addr='ca.example.com ' > family='2' > -- SSL3: Server Certificate Validated. > PR_Write wrote 42 bytes from bigBuf > bytes: [GET /ca/admin/ca/getDomainXML HTTP/1.0 > > ] > do_writes shutting down send socket > do_writes exiting with (failure = 0) > connection 1 read 252 bytes (252 total). > these bytes read: > connection 1 read 252 bytes total. ----------------------------- > [Sun Sep 30 23:23:25 2012] [error] [client 192.168.3.203] Could not find httpd.xml in > /usr/sbin/ at /var/lib/pki-ra/lib/perl/PKI/RA/DisplayCertChainPanel.pm line 228\n, > referer: https://ra.example.com:12890/ra/admin/console/config/wizard > [Sun Sep 30 23:23:25 2012] [info] Connection to child 10 closed (server ra.iris.lk:12890 > , client 192.168.3.203) > ---------------------------------------------------------------------------------------------------------------------------- > > > I Tried reinstalling the RA instance, but got the same result. > > Highly Appreciated If some expert could help me on this. > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From techpkiuser at gmail.com Mon Oct 1 05:51:45 2012 From: techpkiuser at gmail.com (pki tech) Date: Mon, 1 Oct 2012 11:21:45 +0530 Subject: [Pki-users] Server Error at RA installation In-Reply-To: <50692E17.4000503@redhat.com> References: <50692E17.4000503@redhat.com> Message-ID: thank you very much for the swift response. I used Fedora 15, because the DogTag website says, DogTag 9.0 is tested for Fedora 15. and it does not say whether its supported for later versions. Thats why i'm still on Fedora 15. http://pki.fedoraproject.org/wiki/PKI_Download#Dogtag_Certificate_System_9.0 Anyway ill try with a later version of Fedora and check whether the error persists. Again, Appreciate your support. On Mon, Oct 1, 2012 at 11:15 AM, Kashyap Chamarthy wrote: > On 10/01/2012 10:59 AM, pki tech wrote: > > Hi Experts, > > > > I'm stuck with an RA installation with Fedora DogTag 9.0 over Fedora 15. > > You seem to be using an out of support Fedora release. > > Hi, the current supported Fedora releases are F16(this will go out of > support very soon, > once F18 releases, which is on its way) and F17. > > Dogtag has been revamped a lot lately. So please try with latest Fedora > and Dogtag10. That > said, I'm afraid, I haven't seen the below error last time when I > configured RA on Fedora. > > It's unlikely you'll get much help till you're able to reproduce this > issue with latest > Dogtag bits on latest Fedora. > > > -- > /kashyap > > > > > I got my root CA and CA instances working fine. Then I started > installing the RA. As it > > progresses, I was prompted to enter the security domain. So I set the > security domain URL > > and certificate chain was loaded. As I pressed next, I got this error as > the response. > > > > > ---------------------------------------------------------------------------------------------------- > > Internal Server Error > > ------------------------ > > The server encountered an internal error or misconfiguration and was > unable to complete > > your request. > > > > Please contact the server administrator, you example com and inform them > of the time the > > error occurred, and anything you might have done that may have caused > the error. > > > > More information about this error may be available in the server error > log. > > > ---------------------------------------------------------------------------------------------------- > > > > > ---------------------------------------------------------------------------------------------------- > > pki-ra error log > > --------------------------- > > > > [Sun Sep 30 23:23:25 2012] [info] Subsequent (No.18) HTTPS request > received for child 10 > > (server ra.example.com:12890 ) > > GET /ca/admin/ca/getDomainXML HTTP/1.0 > > > > port: 9445 > > addr='ca.example.com ' > > family='2' > > -- SSL3: Server Certificate Validated. > > PR_Write wrote 42 bytes from bigBuf > > bytes: [GET /ca/admin/ca/getDomainXML HTTP/1.0 > > > > ] > > do_writes shutting down send socket > > do_writes exiting with (failure = 0) > > connection 1 read 252 bytes (252 total). > > these bytes read: > > connection 1 read 252 bytes total. ----------------------------- > > [Sun Sep 30 23:23:25 2012] [error] [client 192.168.3.203] Could not find > httpd.xml in > > /usr/sbin/ at /var/lib/pki-ra/lib/perl/PKI/RA/DisplayCertChainPanel.pm > line 228\n, > > referer: https://ra.example.com:12890/ra/admin/console/config/wizard > > [Sun Sep 30 23:23:25 2012] [info] Connection to child 10 closed (server > ra.iris.lk:12890 > > , client 192.168.3.203) > > > ---------------------------------------------------------------------------------------------------------------------------- > > > > > > I Tried reinstalling the RA instance, but got the same result. > > > > Highly Appreciated If some expert could help me on this. > > > > > > > > _______________________________________________ > > 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 alee at redhat.com Mon Oct 1 12:59:03 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 01 Oct 2012 08:59:03 -0400 Subject: [Pki-users] Server Error at RA installation In-Reply-To: References: <50692E17.4000503@redhat.com> Message-ID: <1349096343.2575.88.camel@aleeredhat.laptop> Dogtag 10 is being released and supported on Fedora 18. Dogtag 9 is supported on fedora 16 and 17. If something does not work on f17, let us know and we'll fix it. It is being used, as noted by John Dennis, extensively by IPA. Ade On Mon, 2012-10-01 at 11:21 +0530, pki tech wrote: > thank you very much for the swift response. > > I used Fedora 15, because the DogTag website says, DogTag 9.0 is > tested for Fedora 15. and it does not say whether its supported for > later versions. Thats why i'm still on Fedora 15. > > http://pki.fedoraproject.org/wiki/PKI_Download#Dogtag_Certificate_System_9.0 > > Anyway ill try with a later version of Fedora and check whether the > error persists. > > Again, Appreciate your support. > > On Mon, Oct 1, 2012 at 11:15 AM, Kashyap Chamarthy > wrote: > On 10/01/2012 10:59 AM, pki tech wrote: > > Hi Experts, > > > > I'm stuck with an RA installation with Fedora DogTag 9.0 > over Fedora 15. > > > You seem to be using an out of support Fedora release. > > Hi, the current supported Fedora releases are F16(this will go > out of support very soon, > once F18 releases, which is on its way) and F17. > > Dogtag has been revamped a lot lately. So please try with > latest Fedora and Dogtag10. That > said, I'm afraid, I haven't seen the below error last time > when I configured RA on Fedora. > > It's unlikely you'll get much help till you're able to > reproduce this issue with latest > Dogtag bits on latest Fedora. > > > -- > /kashyap > > > > > I got my root CA and CA instances working fine. Then I > started installing the RA. As it > > progresses, I was prompted to enter the security domain. So > I set the security domain URL > > and certificate chain was loaded. As I pressed next, I got > this error as the response. > > > > > ---------------------------------------------------------------------------------------------------- > > Internal Server Error > > ------------------------ > > The server encountered an internal error or misconfiguration > and was unable to complete > > your request. > > > > Please contact the server administrator, you example com and > inform them of the time the > > error occurred, and anything you might have done that may > have caused the error. > > > > More information about this error may be available in the > server error log. > > > ---------------------------------------------------------------------------------------------------- > > > > > ---------------------------------------------------------------------------------------------------- > > pki-ra error log > > --------------------------- > > > > [Sun Sep 30 23:23:25 2012] [info] Subsequent (No.18) HTTPS > request received for child 10 > > > (server ra.example.com:12890 ) > > GET /ca/admin/ca/getDomainXML HTTP/1.0 > > > > port: 9445 > > > addr='ca.example.com ' > > family='2' > > -- SSL3: Server Certificate Validated. > > PR_Write wrote 42 bytes from bigBuf > > bytes: [GET /ca/admin/ca/getDomainXML HTTP/1.0 > > > > ] > > do_writes shutting down send socket > > do_writes exiting with (failure = 0) > > connection 1 read 252 bytes (252 total). > > these bytes read: > > connection 1 read 252 bytes total. > ----------------------------- > > [Sun Sep 30 23:23:25 2012] [error] [client 192.168.3.203] > Could not find httpd.xml in > > /usr/sbin/ > at /var/lib/pki-ra/lib/perl/PKI/RA/DisplayCertChainPanel.pm > line 228\n, > > referer: > https://ra.example.com:12890/ra/admin/console/config/wizard > > [Sun Sep 30 23:23:25 2012] [info] Connection to child 10 > closed (server ra.iris.lk:12890 > > > , client 192.168.3.203) > > > ---------------------------------------------------------------------------------------------------------------------------- > > > > > > I Tried reinstalling the RA instance, but got the same > result. > > > > Highly Appreciated If some expert could help me on this. > > > > > > > > > _______________________________________________ > > 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 cfu at redhat.com Mon Oct 1 20:22:33 2012 From: cfu at redhat.com (Christina Fu) Date: Mon, 01 Oct 2012 13:22:33 -0700 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <50647FFF.9000001@redhat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>, <50627A89.9080407@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> <50647FFF.9000001@redhat.com> Message-ID: <5069FB89.6070606@redhat.com> Hi Jamil, I see the issue now. I agree there is an issue with the OID. In fact, the hashalg (2) is missing from not just SHA256, but also SHA384 and SHA512 as well. Please go ahead and file a bug for JSS so it could be scheduled for future release. It will probably be automatically assigned to me by default. thanks, Christina On 09/27/2012 09:34 AM, Christina Fu wrote: > Hi Jamil, > > I am running a variant of jss-4.2.6-23 (with one extra patch that I > have not had time to push/build, but it has nothing to do with your > suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I > develop on RHEL. > > Yes, if you'd send in your code with precise reproducing steps, I > might be able to look into it sooner. > > Christina > > On 09/25/2012 11:10 PM, Nimeh, Jamil wrote: >> Hi Christina, thank you very much for getting back to me. >> >> I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. >> That seems to work across the board with JSS and Dogtag (otherwise I >> could never sign a cert with SHA-256, I suppose). I'd be curious to >> know what version of JSS is on your RHEL/RHCS8.1 machine, and perhaps >> what NSS version. On my Fedora box it's JSS 4.2.6 and NSS 3.13.4. >> Maybe something different between the bits we're running? >> >> I've run into the issue when a PKCS#7 or CMS signedData message is >> created. In those cases, the SHA-256 OID would normally be asserted >> in two locations: >> 1. In the DigestAlgorithmIdentifiers segment of the SignedData object >> (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly asserted here. >> >> 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see >> RFC 5652 5.3): This is where the OID gets messed up with SHA-2 algs. >> Since there is only one signer, the DigestAlgorithmIdentifiers >> section at the beginning would have only one OID, the SHA-256 one, >> and that OID should be repeated again in the SignerInfo. >> >> What happens though is that the SignerInfo's >> DigestAlgorithmIdentifier will show up with an OID of >> 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This >> appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6 is >> what comes down when the dogtag packages are pulled with yum, so I >> wasn't sure if I could pop in a newer JSS safely. >> >> Tomorrow I'll take my doctored up CMCRevoke and cook up two messages, >> one where I load the 4.2.6 JSS and one where I do 4.3 and I'll send >> you the DER encodings so you can see what I'm talking about. I don't >> recall, but I think the bug report for 824624 might have sample SCEP >> CertRep messages from the CA, which show the issue using PKCS#7. >> >> Once again, thank you very much for taking the time to look at this. >> >> --Jamil >> >> ------------------------------------------------------------------------ >> *From:* pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] >> on behalf of Christina Fu [cfu at redhat.com] >> *Sent:* Tuesday, September 25, 2012 8:46 PM >> *To:* pki-users at redhat.com >> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages >> failing to verify on server >> >> Hi Jamil, >> >> I tried to reproduce your issue, but I seemed to be able to generate >> CMC revocation request with SHA-256 digest. I have to admit that my >> main development machine is RHEL and I work on RHCS8.1 tree. >> >> I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the >> exception with DSA), compiled, and it just worked. Did you do >> anything different? >> >> I could see in dumpasn1 where SHA245 is in place: >> C-Sequence (13) >> Object Identifier (9) >> 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) >> NULL (0) >> Christina >> >> On 09/19/2012 11:19 AM, Christina Fu wrote: >>> Hi Jamil, >>> >>> We made an effort to support SHA2 where we can but might have missed >>> a few places. I'll look into this and hopefully be able to get back >>> to you in a few days. >>> >>> thanks, >>> Christina >>> >>> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: >>>> >>>> Hello Dogtag Gurus, >>>> >>>> I have been trying to issue CMC revocation messages signed with >>>> SHA-256, but the server fails to validate the message in the >>>> CMCAuth java policy module. If I leave all fields the same but >>>> change the signature algorithm to SHA-1 then everything seems to >>>> work fine. >>>> >>>> I suspect this is another side-effect of the root-cause for bug >>>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 >>>> messages are created using any of the SHA-2 variants, the OIDs get >>>> messed up. This happened with SCEP responses from the CA (the bug >>>> referenced above) and I had it happen with the CMC revoke >>>> modifications I made. The latter issue was fixed by pulling down >>>> JSS 4.3 and loading that jar in the classpath for the modified >>>> CMCRevoke tool. However, on the server side I ended up seeing >>>> verification failures. >>>> >>>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one >>>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with >>>> JSS 4.3 or later. Is that still the case with the latest 9.0 packages? >>>> >>>> >>>> Has anyone had any success generating these CMC messages using >>>> SHA-2 hash algs and getting Dogtag to accept them? >>>> >>>> >>>> Thanks, >>>> >>>> Jamil >>>> >>>> >>>> _______________________________________________ >>>> 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 alee at redhat.com Wed Oct 3 02:44:29 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 02 Oct 2012 22:44:29 -0400 Subject: [Pki-users] Announcing Dogtag 10.0.0 alpha 2 release Message-ID: <1349232270.27199.7.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 alpha 2. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.37.a2.fc18 pki-ra-10.0.0-0.8.a2.fc18 pki-tps-10.0.0-0.8.a2.fc18 dogtag-pki-10.0.0-0.9.a2.fc18 dogtag-pki-theme-10.0.0-0.2.a2.fc18 pki-console-10.0.0-0.8.a2.fc18 == Highlights since Dogtag v. 10.0.0 alpha 1 (Sept 14 2012) == * Dogtag 10 can now clone from Dogtag 9 masters. We will fall back to the old installation servlet if needed. (**) * Startup state of a server can be determined from the getStatus() servlet (**) * Consistent database user provided during installation for client authentication (used in IPA merged database install) * Fixed package dependency issue with pki-symkey (**) * pki-setup merged into pki-server (**) * Audit Cert Renewal time extended to two years (**) * Versioning added to jar manifest files and VERSION file and reported in getStatus * ECC enhancements in DRM and TMS environment * Addition of time based searches in preparation for randomized serial numbers * Enhanced escaping of LDAP attributes * Improved transition control for token operations in the TPS. ** denotes IPA related/reported issue == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == Ade Lee (4): 761a047 Updated release to a2 854ecce fall back to old interface for installtoken if needed 11e05d3 Use getStatus servlet to provide startup status e1666df Changes to use standard dbuser Andrew Wnuk (1): f944641 time based searches Christina Fu (5): 7b3df7e https://fedorahosted.org/pki/ticket/252 - TMS - ECC Key Recovery 528fda5 TMS key recovery part of - Bug 737122 - DRM: during archiving and recovering, wrapping unwrapping keys should be done in the token f4ecf48 (fixed warning for) task #304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) e689561 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) 6257d32 https://fedorahosted.org/pki/ticket/304 TMS ECC infrastructure (enrollment with client-side and server-side key generation, and key archival) Endi Dewata (11): f81718c Using RPM version number in CMake. aa1c7e7 Added package checking for pkispawn. 87d290d Added version number into server status. 9368ef4 Added VERSION file. 1726794 Renamed escapeDN() into escapeRDNValue(). 4ba74f7 Merged pki-setup into pki-server. 156ba56 Added DN and filter escaping in ConfigurationUtils. 947ab8a Removed duplicate DN escaping methods. 715d89d Added DN and filter escaping in UGSubsystem. 7b737b2 Fixed conflicting log4j.properties. 8ed86a7 Fixed problems with optional pki-symkey. Jack Magne (1): 9173b43 Provide default for operations transition list, # 858816. Matthew Harmsen (2): d450525 Correctly resolve symlinks in subdirectories f5b8ea5 Audit Cert Renewal From techpkiuser at gmail.com Wed Oct 3 06:45:50 2012 From: techpkiuser at gmail.com (pki tech) Date: Wed, 3 Oct 2012 12:15:50 +0530 Subject: [Pki-users] Server Error at RA installation In-Reply-To: <1349096343.2575.88.camel@aleeredhat.laptop> References: <50692E17.4000503@redhat.com> <1349096343.2575.88.camel@aleeredhat.laptop> Message-ID: wow...Thanks I feel very confident with what you just said. Will try out Fedora 17. On Mon, Oct 1, 2012 at 6:29 PM, Ade Lee wrote: > Dogtag 10 is being released and supported on Fedora 18. > > Dogtag 9 is supported on fedora 16 and 17. If something does not work > on f17, let us know and we'll fix it. It is being used, as noted by > John Dennis, extensively by IPA. > > Ade > > On Mon, 2012-10-01 at 11:21 +0530, pki tech wrote: > > thank you very much for the swift response. > > > > I used Fedora 15, because the DogTag website says, DogTag 9.0 is > > tested for Fedora 15. and it does not say whether its supported for > > later versions. Thats why i'm still on Fedora 15. > > > > > http://pki.fedoraproject.org/wiki/PKI_Download#Dogtag_Certificate_System_9.0 > > > > Anyway ill try with a later version of Fedora and check whether the > > error persists. > > > > Again, Appreciate your support. > > > > On Mon, Oct 1, 2012 at 11:15 AM, Kashyap Chamarthy > > wrote: > > On 10/01/2012 10:59 AM, pki tech wrote: > > > Hi Experts, > > > > > > I'm stuck with an RA installation with Fedora DogTag 9.0 > > over Fedora 15. > > > > > > You seem to be using an out of support Fedora release. > > > > Hi, the current supported Fedora releases are F16(this will go > > out of support very soon, > > once F18 releases, which is on its way) and F17. > > > > Dogtag has been revamped a lot lately. So please try with > > latest Fedora and Dogtag10. That > > said, I'm afraid, I haven't seen the below error last time > > when I configured RA on Fedora. > > > > It's unlikely you'll get much help till you're able to > > reproduce this issue with latest > > Dogtag bits on latest Fedora. > > > > > > -- > > /kashyap > > > > > > > > I got my root CA and CA instances working fine. Then I > > started installing the RA. As it > > > progresses, I was prompted to enter the security domain. So > > I set the security domain URL > > > and certificate chain was loaded. As I pressed next, I got > > this error as the response. > > > > > > > > > ---------------------------------------------------------------------------------------------------- > > > Internal Server Error > > > ------------------------ > > > The server encountered an internal error or misconfiguration > > and was unable to complete > > > your request. > > > > > > Please contact the server administrator, you example com and > > inform them of the time the > > > error occurred, and anything you might have done that may > > have caused the error. > > > > > > More information about this error may be available in the > > server error log. > > > > > > ---------------------------------------------------------------------------------------------------- > > > > > > > > > ---------------------------------------------------------------------------------------------------- > > > pki-ra error log > > > --------------------------- > > > > > > [Sun Sep 30 23:23:25 2012] [info] Subsequent (No.18) HTTPS > > request received for child 10 > > > > > (server ra.example.com:12890 ) > > > GET /ca/admin/ca/getDomainXML HTTP/1.0 > > > > > > port: 9445 > > > > > addr='ca.example.com ' > > > family='2' > > > -- SSL3: Server Certificate Validated. > > > PR_Write wrote 42 bytes from bigBuf > > > bytes: [GET /ca/admin/ca/getDomainXML HTTP/1.0 > > > > > > ] > > > do_writes shutting down send socket > > > do_writes exiting with (failure = 0) > > > connection 1 read 252 bytes (252 total). > > > these bytes read: > > > connection 1 read 252 bytes total. > > ----------------------------- > > > [Sun Sep 30 23:23:25 2012] [error] [client 192.168.3.203] > > Could not find httpd.xml in > > > /usr/sbin/ > > at /var/lib/pki-ra/lib/perl/PKI/RA/DisplayCertChainPanel.pm > > line 228\n, > > > referer: > > https://ra.example.com:12890/ra/admin/console/config/wizard > > > [Sun Sep 30 23:23:25 2012] [info] Connection to child 10 > > closed (server ra.iris.lk:12890 > > > > > , client 192.168.3.203) > > > > > > ---------------------------------------------------------------------------------------------------------------------------- > > > > > > > > > I Tried reinstalling the RA instance, but got the same > > result. > > > > > > Highly Appreciated If some expert could help me on this. > > > > > > > > > > > > > > _______________________________________________ > > > 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 alee at redhat.com Tue Oct 9 15:03:40 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 09 Oct 2012 11:03:40 -0400 Subject: [Pki-users] Announcing Dogtag 10.0.0 beta 1 release Message-ID: <1349795021.19017.102.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 beta 1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.43.b1.fc18 pki-ra-10.0.0-0.9.b1.fc18 pki-tps-10.0.0-0.9.b1.fc18 dogtag-pki-10.0.0-0.10.b1.fc18 dogtag-pki-theme-10.0.0-0.2.b1.fc18 pki-console-10.0.0-0.8.b1.fc18 == Highlights since Dogtag v. 10.0.0 alpha 2 (Oct 1 2012) == * Merged pki-silent into pki-server. * Added Provides to packages replacing obsolete packages. * Added needed link for updated d9 -> d10 instances. Found in IPA testing. * Backed up CS.cfg before upgrading from d9 -> d10 * New selinux policy for all components. The Java components now take advantage of a tomcat domain defined in the base selinux policy, and the RA/TPS policies have been cleaned up considerably. The policy that is now delivered is very close to the final version that will be delivered in the base policy. That will be a deliverable for beta 2. * Selinux context for startup scripts for all components set so that runcon is not required. * Cleaned up lock and pid files generation and removal for java processes. * Rebuilt packages against the latest F18 base selinux policy packages to resolve an issue in installing pki-selinux due to removal of a boolean in F18 base selinux policies. This issue was reported by IPA. == Notes for F17 == * F17 requires an selinux version that is still in updates-testing. Enable this repo to upgrade accordingly. * F17 tomcat has a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Prior to creating an instance, you need to perform the following workaround: In the file, /usr/sbin/tomcat-sysd, change the line: export CATALINA_PID="/var/run/${NAME}.pid" to: export CATALINA_PID="${CATALINA_PID:-/var/run/${NAME}.pid}" == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == Ade Lee (11): 5ef10ba Update selinux-policy version to fix error from latest policy 81596ba fix spec typo 919434b Added build requires for version of selinux-policy-devel 5014442 Update release to b1 9cd11bc Fix name of CS.cfg backup file 63237d3 Backup CS.cfg before d10 update da73f97 Changes to start pki_ra and pki_tps in correct context 6e79c7c add selinux context for pkidaemon, remove unneeded pid/lock code f542060 move common policy into tps, ra templates dbc6dec Use the tomcat selinux domain for the Java processes 3d5dc3b Added needed link for updated d9 -> d10 instances Endi Dewata (3): 23c70bd Merged pki-silent into pki-server. 79a3d82 Renamed "shared" folder to "server". 753d55e Added Provides to packages replacing obsolete packages. From cfu at redhat.com Wed Oct 10 21:01:12 2012 From: cfu at redhat.com (Christina Fu) Date: Wed, 10 Oct 2012 14:01:12 -0700 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>, <50627A89.9080407@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> <50647FFF.9000001@redhat.com>, <5069FB89.6070606@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com> Message-ID: <5075E218.5070404@redhat.com> Hi Jamil, We branched off of JSS 4.2.6 and created several patches ever since. Merging with upstream JSS (4.3) has been planned to be done within the next year also. Until then, we are not able to provide information with confidence on how JSS4.3 would work with our current releases. If any Dogtag community member has tried and has answer for you, it would be great. Christina On 10/10/2012 09:54 AM, Nimeh, Jamil wrote: > > [Re-reply to include pki-devel at redhat.com ] > > Hi Christina, sorry for taking so long to get back to you. I can file > this against JSS, but given that it's a down-rev version (4.2.6) and > appears to be fixed in JSS 4.3, is it worth filing this? > > I guess the bigger question that affects SHA-2 algorithms as they are > implemented in Dogtag is whether or not I can safely use JSS 4.3 with > Dogtag 9.0.x? 4.2.6 is what appears to be the latest rev in the F15 > yum repositories. Do you (or anyone on your team maybe) know if there > are incompatibilities between JSS 4.2.6 and 4.3 that would break a > Dogtag 9 installation? > > If it can work the areas that this would affect would be: > > * Proper creation of SCEP CertRep messages when using SHA-2 algs > * The ability to sign OCSP responses using something other than > SHA-1 (can that be changed? I don't see a tuneable for this) > * The ability to submit CMC revocation messages using SHA-2 and > have it properly validated before acting on it in the CA. > > There might be other areas as well (maybe in other CMC related > functions) but those three areas are the ones I've run into. > > > Thanks, > > Jamil > > ------------------------------------------------------------------------ > *From:* pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on > behalf of Christina Fu [cfu at redhat.com] > *Sent:* Monday, October 01, 2012 1:22 PM > *To:* pki-users at redhat.com > *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages > failing to verify on server > > Hi Jamil, > > I see the issue now. I agree there is an issue with the OID. In > fact, the hashalg (2) is missing from not just SHA256, but also SHA384 > and SHA512 as well. > > Please go ahead and file a bug for JSS so it could be scheduled for > future release. It will probably be automatically assigned to me by > default. > > thanks, > Christina > > On 09/27/2012 09:34 AM, Christina Fu wrote: >> Hi Jamil, >> >> I am running a variant of jss-4.2.6-23 (with one extra patch that I >> have not had time to push/build, but it has nothing to do with your >> suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I >> develop on RHEL. >> >> Yes, if you'd send in your code with precise reproducing steps, I >> might be able to look into it sooner. >> >> Christina >> >> On 09/25/2012 11:10 PM, Nimeh, Jamil wrote: >>> Hi Christina, thank you very much for getting back to me. >>> >>> I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. >>> That seems to work across the board with JSS and Dogtag (otherwise I >>> could never sign a cert with SHA-256, I suppose). I'd be curious to >>> know what version of JSS is on your RHEL/RHCS8.1 machine, and >>> perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS >>> 3.13.4. Maybe something different between the bits we're running? >>> >>> I've run into the issue when a PKCS#7 or CMS signedData message is >>> created. In those cases, the SHA-256 OID would normally be asserted >>> in two locations: >>> 1. In the DigestAlgorithmIdentifiers segment of the SignedData >>> object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly >>> asserted here. >>> >>> 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see >>> RFC 5652 5.3): This is where the OID gets messed up with SHA-2 >>> algs. Since there is only one signer, the >>> DigestAlgorithmIdentifiers section at the beginning would have only >>> one OID, the SHA-256 one, and that OID should be repeated again in >>> the SignerInfo. >>> >>> What happens though is that the SignerInfo's >>> DigestAlgorithmIdentifier will show up with an OID of >>> 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This >>> appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6 >>> is what comes down when the dogtag packages are pulled with yum, so >>> I wasn't sure if I could pop in a newer JSS safely. >>> >>> Tomorrow I'll take my doctored up CMCRevoke and cook up two >>> messages, one where I load the 4.2.6 JSS and one where I do 4.3 and >>> I'll send you the DER encodings so you can see what I'm talking >>> about. I don't recall, but I think the bug report for 824624 might >>> have sample SCEP CertRep messages from the CA, which show the issue >>> using PKCS#7. >>> >>> Once again, thank you very much for taking the time to look at this. >>> >>> --Jamil >>> >>> ------------------------------------------------------------------------ >>> *From:* pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] >>> on behalf of Christina Fu [cfu at redhat.com] >>> *Sent:* Tuesday, September 25, 2012 8:46 PM >>> *To:* pki-users at redhat.com >>> *Subject:* Re: [Pki-users] SHA-256 signed CMC revocation messages >>> failing to verify on server >>> >>> Hi Jamil, >>> >>> I tried to reproduce your issue, but I seemed to be able to generate >>> CMC revocation request with SHA-256 digest. I have to admit that my >>> main development machine is RHEL and I work on RHCS8.1 tree. >>> >>> I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the >>> exception with DSA), compiled, and it just worked. Did you do >>> anything different? >>> >>> I could see in dumpasn1 where SHA245 is in place: >>> C-Sequence (13) >>> Object Identifier (9) >>> 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) >>> NULL (0) >>> Christina >>> >>> On 09/19/2012 11:19 AM, Christina Fu wrote: >>>> Hi Jamil, >>>> >>>> We made an effort to support SHA2 where we can but might have >>>> missed a few places. I'll look into this and hopefully be able to >>>> get back to you in a few days. >>>> >>>> thanks, >>>> Christina >>>> >>>> On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: >>>>> >>>>> Hello Dogtag Gurus, >>>>> >>>>> I have been trying to issue CMC revocation messages signed with >>>>> SHA-256, but the server fails to validate the message in the >>>>> CMCAuth java policy module. If I leave all fields the same but >>>>> change the signature algorithm to SHA-1 then everything seems to >>>>> work fine. >>>>> >>>>> I suspect this is another side-effect of the root-cause for bug >>>>> 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 >>>>> messages are created using any of the SHA-2 variants, the OIDs get >>>>> messed up. This happened with SCEP responses from the CA (the bug >>>>> referenced above) and I had it happen with the CMC revoke >>>>> modifications I made. The latter issue was fixed by pulling down >>>>> JSS 4.3 and loading that jar in the classpath for the modified >>>>> CMCRevoke tool. However, on the server side I ended up seeing >>>>> verification failures. >>>>> >>>>> I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one >>>>> point I had heard that Dogtag 9.0.X wasn't 100% safe to run with >>>>> JSS 4.3 or later. Is that still the case with the latest 9.0 >>>>> packages? >>>>> >>>>> >>>>> Has anyone had any success generating these CMC messages using >>>>> SHA-2 hash algs and getting Dogtag to accept them? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jamil >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Jamil.Nimeh at viasat.com Wed Oct 10 22:15:26 2012 From: Jamil.Nimeh at viasat.com (Nimeh, Jamil) Date: Wed, 10 Oct 2012 22:15:26 +0000 Subject: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server In-Reply-To: <5075E218.5070404@redhat.com> References: <6A95FA630FB5124C886BAD159CDBA1F016D5CA54@wdc1exchmbxp05.hq.corp.viasat.com> <505A0C9D.1000709@redhat.com>, <50627A89.9080407@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5E063@wdc1exchmbxp05.hq.corp.viasat.com> <50647FFF.9000001@redhat.com>,<5069FB89.6070606@redhat.com> <6A95FA630FB5124C886BAD159CDBA1F016D5FF27@wdc1exchmbxp05.hq.corp.viasat.com>, <5075E218.5070404@redhat.com> Message-ID: <6A95FA630FB5124C886BAD159CDBA1F016D5FF97@wdc1exchmbxp05.hq.corp.viasat.com> Thanks Christina for the feedback. I guess I can give it a try and see what happens. At some point I may have to look into pushing forward to Dogtag 10/Fedora 18 and see if those same issues occur on a newer system. Given that you ran similar tests on other systems and didn't see what I found on F15 maybe an updated system will work. I'll give it a try when I have some spare cycles and let you know. Thanks, Jamil ________________________________ From: Christina Fu [cfu at redhat.com] Sent: Wednesday, October 10, 2012 2:01 PM To: Nimeh, Jamil Cc: pki-devel at redhat.com; pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, We branched off of JSS 4.2.6 and created several patches ever since. Merging with upstream JSS (4.3) has been planned to be done within the next year also. Until then, we are not able to provide information with confidence on how JSS4.3 would work with our current releases. If any Dogtag community member has tried and has answer for you, it would be great. Christina On 10/10/2012 09:54 AM, Nimeh, Jamil wrote: [Re-reply to include pki-devel at redhat.com] Hi Christina, sorry for taking so long to get back to you. I can file this against JSS, but given that it's a down-rev version (4.2.6) and appears to be fixed in JSS 4.3, is it worth filing this? I guess the bigger question that affects SHA-2 algorithms as they are implemented in Dogtag is whether or not I can safely use JSS 4.3 with Dogtag 9.0.x? 4.2.6 is what appears to be the latest rev in the F15 yum repositories. Do you (or anyone on your team maybe) know if there are incompatibilities between JSS 4.2.6 and 4.3 that would break a Dogtag 9 installation? If it can work the areas that this would affect would be: * Proper creation of SCEP CertRep messages when using SHA-2 algs * The ability to sign OCSP responses using something other than SHA-1 (can that be changed? I don't see a tuneable for this) * The ability to submit CMC revocation messages using SHA-2 and have it properly validated before acting on it in the CA. There might be other areas as well (maybe in other CMC related functions) but those three areas are the ones I've run into. Thanks, Jamil ________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on behalf of Christina Fu [cfu at redhat.com] Sent: Monday, October 01, 2012 1:22 PM To: pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, I see the issue now. I agree there is an issue with the OID. In fact, the hashalg (2) is missing from not just SHA256, but also SHA384 and SHA512 as well. Please go ahead and file a bug for JSS so it could be scheduled for future release. It will probably be automatically assigned to me by default. thanks, Christina On 09/27/2012 09:34 AM, Christina Fu wrote: Hi Jamil, I am running a variant of jss-4.2.6-23 (with one extra patch that I have not had time to push/build, but it has nothing to do with your suspected area). For nss, I'm running nss-3.13.5-8.el5. Again, I develop on RHEL. Yes, if you'd send in your code with precise reproducing steps, I might be able to look into it sooner. Christina On 09/25/2012 11:10 PM, Nimeh, Jamil wrote: Hi Christina, thank you very much for getting back to me. I haven't seen the problem with the PKCS#1 SHA-256 with RSA OID. That seems to work across the board with JSS and Dogtag (otherwise I could never sign a cert with SHA-256, I suppose). I'd be curious to know what version of JSS is on your RHEL/RHCS8.1 machine, and perhaps what NSS version. On my Fedora box it's JSS 4.2.6 and NSS 3.13.4. Maybe something different between the bits we're running? I've run into the issue when a PKCS#7 or CMS signedData message is created. In those cases, the SHA-256 OID would normally be asserted in two locations: 1. In the DigestAlgorithmIdentifiers segment of the SignedData object (see RFC 5652 5.1): CMS/PKCS#7 objects have it properly asserted here. 2. In the DigestAlgorithmIdentifier portion of the SignerInfo (see RFC 5652 5.3): This is where the OID gets messed up with SHA-2 algs. Since there is only one signer, the DigestAlgorithmIdentifiers section at the beginning would have only one OID, the SHA-256 one, and that OID should be repeated again in the SignerInfo. What happens though is that the SignerInfo's DigestAlgorithmIdentifier will show up with an OID of 2.16.840.1.101.3.4.1 when it should be 2.16.840.1.101.3.4.2.1. This appears to happen with JSS 4.2.6, but not with JSS 4.3. But 4.2.6 is what comes down when the dogtag packages are pulled with yum, so I wasn't sure if I could pop in a newer JSS safely. Tomorrow I'll take my doctored up CMCRevoke and cook up two messages, one where I load the 4.2.6 JSS and one where I do 4.3 and I'll send you the DER encodings so you can see what I'm talking about. I don't recall, but I think the bug report for 824624 might have sample SCEP CertRep messages from the CA, which show the issue using PKCS#7. Once again, thank you very much for taking the time to look at this. --Jamil ________________________________ From: pki-users-bounces at redhat.com [pki-users-bounces at redhat.com] on behalf of Christina Fu [cfu at redhat.com] Sent: Tuesday, September 25, 2012 8:46 PM To: pki-users at redhat.com Subject: Re: [Pki-users] SHA-256 signed CMC revocation messages failing to verify on server Hi Jamil, I tried to reproduce your issue, but I seemed to be able to generate CMC revocation request with SHA-256 digest. I have to admit that my main development machine is RHEL and I work on RHCS8.1 tree. I changed all "SHA1" to "SHA256" in CMCRevoke.java (with the exception with DSA), compiled, and it just worked. Did you do anything different? I could see in dumpasn1 where SHA245 is in place: C-Sequence (13) Object Identifier (9) 1 2 840 113549 1 1 11 (PKCS #1 SHA-256 With RSA Encryption) NULL (0) Christina On 09/19/2012 11:19 AM, Christina Fu wrote: Hi Jamil, We made an effort to support SHA2 where we can but might have missed a few places. I'll look into this and hopefully be able to get back to you in a few days. thanks, Christina On 09/19/2012 12:44 AM, Nimeh, Jamil wrote: Hello Dogtag Gurus, I have been trying to issue CMC revocation messages signed with SHA-256, but the server fails to validate the message in the CMCAuth java policy module. If I leave all fields the same but change the signature algorithm to SHA-1 then everything seems to work fine. I suspect this is another side-effect of the root-cause for bug 824624. It seems like in certain cases with JSS 4.2.6 when PKCS#7 messages are created using any of the SHA-2 variants, the OIDs get messed up. This happened with SCEP responses from the CA (the bug referenced above) and I had it happen with the CMC revoke modifications I made. The latter issue was fixed by pulling down JSS 4.3 and loading that jar in the classpath for the modified CMCRevoke tool. However, on the server side I ended up seeing verification failures. I'm running pki-common-9.0.20, jss 4.2.6, and NSS 3.13.4. At one point I had heard that Dogtag 9.0.X wasn't 100% safe to run with JSS 4.3 or later. Is that still the case with the latest 9.0 packages? Has anyone had any success generating these CMC messages using SHA-2 hash algs and getting Dogtag to accept them? Thanks, Jamil _______________________________________________ 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 Nicholas.Ritter at americantv.com Thu Oct 11 14:20:24 2012 From: Nicholas.Ritter at americantv.com (Ritter, Nicholas) Date: Thu, 11 Oct 2012 14:20:24 +0000 Subject: [Pki-users] Dogtag and certificate VPN Message-ID: Is anyone using, or has tested, Dogtag with certificate based VPN? And more specifically with Cisco ASA Anyconnect and IPSEC VPN? I searched through the dogtag mailing list archive and the Cisco forums and found someone tried to do this in 2010 and had problems that I can only assume there was no resolution to. The last posting I saw was someone giving the blanket vendor reason of "Cisco does not support that CA". Given that there has not been a posting since, and that was two years ago, I was curious if anyone had tested/implemented it? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From Charles.Jennings at corp.earthlink.com Thu Oct 11 15:21:09 2012 From: Charles.Jennings at corp.earthlink.com (Jennings, Charles) Date: Thu, 11 Oct 2012 10:21:09 -0500 Subject: [Pki-users] Dogtag and certificate VPN Message-ID: I can tell you that I have used DogTag 1.3 with Cisco based IPSec VPNs between routers (not using ASAs) with no problem - other than - I had to change the RSA hashing algorithm at setup to utilize SHA-1 instead of the default of SHA-256 - which the cisco routers I was testing with did not support. Charles Jennings From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Ritter, Nicholas Sent: Thursday, October 11, 2012 9:20 AM To: pki-users at redhat.com Subject: [Pki-users] Dogtag and certificate VPN Is anyone using, or has tested, Dogtag with certificate based VPN? And more specifically with Cisco ASA Anyconnect and IPSEC VPN? I searched through the dogtag mailing list archive and the Cisco forums and found someone tried to do this in 2010 and had problems that I can only assume there was no resolution to. The last posting I saw was someone giving the blanket vendor reason of "Cisco does not support that CA". Given that there has not been a posting since, and that was two years ago, I was curious if anyone had tested/implemented it? Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From awnuk at redhat.com Thu Oct 11 16:34:08 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Thu, 11 Oct 2012 09:34:08 -0700 Subject: [Pki-users] Dogtag and certificate VPN In-Reply-To: References: Message-ID: <5076F500.5000200@redhat.com> Hi Nick, Dogtag and RHCS have been tested with Cisco ASA 5100 in the past. CA tests successfully issued certificates to Cisco ASA 5100 router via SCEP protocol. However, router's bug was discovered during this testing showing that router does not generates keys with proper parity. This issue occurs only when CA is connected to NetHSM since NetHSM rejects keys without proper parity. If you are experiencing this issue, you may search Cisco software updates for a fix. Thank you, Andrew On 10/11/2012 07:20 AM, Ritter, Nicholas wrote: > > Is anyone using, or has tested, Dogtag with certificate based VPN? And > more specifically with Cisco ASA Anyconnect and IPSEC VPN? > > I searched through the dogtag mailing list archive and the Cisco > forums and found someone tried to do this in 2010 and had problems > that I can only assume there was no resolution to. The last posting I > saw was someone giving the blanket vendor reason of "Cisco does not > support that CA". Given that there has not been a posting since, and > that was two years ago, I was curious if anyone had tested/implemented it? > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmk at ncf.ca Wed Oct 17 19:52:11 2012 From: dmk at ncf.ca (Dwayne MacKinnon) Date: Wed, 17 Oct 2012 15:52:11 -0400 Subject: [Pki-users] Problems with Dogtag and CA cert signed by External CA Message-ID: <1879296.Sx4g43KeR8@hudson.private.lan> Hi all, A helpful fellow called alee on #dogtag-pki suggested I write the list. I've been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17. I'm looking to use dogtag to run a subordinate CA that does all our everyday PKI stuff. So when I used pki-create and went into the webform, I went the "create a csr" route and signed it using a root CA I'd set up using openssl. Everything seemed to work out fine, until I got to the point where I was restarting pki-cad (using systemctl restart pki-cad at pki-ca.service). It wouldn't start. With alee's help I tracked it down to a failure of SystemCertsVerification during the selftests. He asked me to submit my debug log to the list, so here it is. Cheers, DMK -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.log Type: text/x-log Size: 1382429 bytes Desc: not available URL: From jdennis at redhat.com Wed Oct 17 20:52:52 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 17 Oct 2012 16:52:52 -0400 Subject: [Pki-users] Problems with Dogtag and CA cert signed by External CA In-Reply-To: <1879296.Sx4g43KeR8@hudson.private.lan> References: <1879296.Sx4g43KeR8@hudson.private.lan> Message-ID: <507F1AA4.80009@redhat.com> On 10/17/2012 03:52 PM, Dwayne MacKinnon wrote: > Hi all, > > A helpful fellow called alee on #dogtag-pki suggested I write the list. I've > been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17. > > I'm looking to use dogtag to run a subordinate CA that does all our everyday > PKI stuff. So when I used pki-create and went into the webform, I went the > "create a csr" route and signed it using a root CA I'd set up using openssl. > > Everything seemed to work out fine, until I got to the point where I was > restarting pki-cad (using systemctl restart pki-cad at pki-ca.service). It > wouldn't start. > > With alee's help I tracked it down to a failure of SystemCertsVerification > during the selftests. > > He asked me to submit my debug log to the list, so here it is. Interestingly enough I'm in the middle of tracking down why NSS will not validate a self signed cert as a CA. I suspect dogtag is calling NSS's CERT_VerifyCertificateNow (or it's equivalent) and passing it a specific usage parameter. There are very specific requirements to accept a CA cert as valid. More valuable than the log would be show us what the cert looks like. I would ordinarily tell you to dump the cert in text form using openssl x509 -text but openssl often omits detailed information on the cert extensions which are critical (no pun intended) here. How about if you also provide us with a PEM formatted version of the cert and we'll use our tools to examine it's contents. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From awnuk at redhat.com Wed Oct 17 23:17:09 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Wed, 17 Oct 2012 16:17:09 -0700 Subject: [Pki-users] Problems with Dogtag and CA cert signed by External CA In-Reply-To: <1879296.Sx4g43KeR8@hudson.private.lan> References: <1879296.Sx4g43KeR8@hudson.private.lan> Message-ID: <507F3C75.6030401@redhat.com> On 10/17/2012 12:52 PM, Dwayne MacKinnon wrote: > Hi all, > > A helpful fellow called alee on #dogtag-pki suggested I write the list. I've > been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17. > > I'm looking to use dogtag to run a subordinate CA that does all our everyday > PKI stuff. So when I used pki-create and went into the webform, I went the > "create a csr" route and signed it using a root CA I'd set up using openssl. > > Everything seemed to work out fine, until I got to the point where I was > restarting pki-cad (using systemctl restartpki-cad at pki-ca.service). It > wouldn't start. > > With alee's help I tracked it down to a failure of SystemCertsVerification > during the selftests. > > He asked me to submit my debug log to the list, so here it is. > > Cheers, > DMK Is it possible to see your root and sub CA certificates? Thank you, Andrew From dmk at ncf.ca Thu Oct 18 15:49:43 2012 From: dmk at ncf.ca (Dwayne MacKinnon) Date: Thu, 18 Oct 2012 11:49:43 -0400 Subject: [Pki-users] Problems with Dogtag and CA cert signed by External CA In-Reply-To: <507F1AA4.80009@redhat.com> References: <1879296.Sx4g43KeR8@hudson.private.lan> <507F1AA4.80009@redhat.com> Message-ID: <1574626.DPzbviIWT1@hudson.private.lan> On October 17, 2012 04:52:52 PM John Dennis wrote: > On 10/17/2012 03:52 PM, Dwayne MacKinnon wrote: > > Hi all, > > > > A helpful fellow called alee on #dogtag-pki suggested I write the list. > > I've been playing with dogtag-pki-9.0.0-10 on 64-bit Fedora 17. > > > > I'm looking to use dogtag to run a subordinate CA that does all our > > everyday PKI stuff. So when I used pki-create and went into the webform, > > I went the "create a csr" route and signed it using a root CA I'd set up > > using openssl. > > > > Everything seemed to work out fine, until I got to the point where I was > > restarting pki-cad (using systemctl restart pki-cad at pki-ca.service). It > > wouldn't start. > > > > With alee's help I tracked it down to a failure of SystemCertsVerification > > during the selftests. > > > > He asked me to submit my debug log to the list, so here it is. > > Interestingly enough I'm in the middle of tracking down why NSS will not > validate a self signed cert as a CA. I suspect dogtag is calling NSS's > CERT_VerifyCertificateNow (or it's equivalent) and passing it a specific > usage parameter. > > There are very specific requirements to accept a CA cert as valid. More > valuable than the log would be show us what the cert looks like. I would > ordinarily tell you to dump the cert in text form using openssl x509 > -text but openssl often omits detailed information on the cert > extensions which are critical (no pun intended) here. How about if you > also provide us with a PEM formatted version of the cert and we'll use > our tools to examine it's contents. Sure. I've generated a clone cert with phony credentials. It's attached. Thanks for the assistance. Cheers, DMK -------------- next part -------------- A non-text attachment was scrubbed... Name: subca_cert.pem Type: application/x-x509-ca-cert Size: 7313 bytes Desc: not available URL: From alee at redhat.com Tue Oct 30 19:17:01 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 30 Oct 2012 15:17:01 -0400 Subject: [Pki-users] Announcing Dogtag 10 Beta 2 Release Message-ID: <1351624621.25507.43.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 beta 2. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-0.48.b2.fc18 pki-ra-10.0.0-0.10.b2.fc18 pki-tps-10.0.0-0.10.b2.fc18 dogtag-pki-10.0.0-0.13.b2.fc18 dogtag-pki-theme-10.0.0-0.4.b2.fc18 pki-console-10.0.0-0.10.b2.fc18 == Highlights since Dogtag v. 10.0.0 beta 1 (Oct 9 2012) == * Selinux policy moved into system selinux policy. For F18, pki-selinux will no longer be built and delivered by the dogtag team. The PKI policy will instead be managed by the selinux base packages team. * Added option to install schema on a clone, rather than simply replicating it. This is to resolve an IPA issue when replicating from a non-merged to a merged database. * Restricted AJP to allow access from localhost only by default. This is an IPA reported issue. * Changes to allow the TPS and RA to install and configure correctly. * Enabled Tomcat security manager and added mechanism to configure custom security policy. * Added CLI tools to obtain security domain information and install tokens. * Refactored REST client classes to support multiple operations over authenticated HTTP session. * Added automatic recovery to the LDAP modification listener. * Added login service to protect REST services including certificate operations, key operations, security domain, TKS and OCSP. * Added option to pkispawn to exit before configuration, in case the installer wants to go through the UI configuration panels. In this way, pkispawn can be operated like pkicreate/pkisilent. * Removed version numbers from jar files to comply with Fedora packaging recommendations. == Notes for F17 == * Only developer builds are available for F17. * F17 tomcat used to have a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you have at least tomcat-7.0.32-1.fc17. == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == akoneru (1): 1485a05 Fix for ticket 384 - Incorrect profiles path referenced alee (15): 80ac796 Fix symkey build dependency 65c17da Update to b2 release 7c105a6 Restrict AJP to localhost only by default 3908d96 Added obsoletes for pki-selinux 278ee60 changes to remove pki-selinux from f18 build 1c45197 Provide option to install, rather than replicate schema to clone 40bcc2c Reorder VLV indexing for clones to avoid errors 643c089 Fixes to get TPS to configure correctly d6634a7 Reverted to old interface and httpclient for installation token. 2a43f48 Added net-tools dependency 35eb608 changes to remind folks not to use pkicreate/pkiremove 8a2d342 Update tomcatjss dependency 283af42 Added pki_tomcat_script_t type and rules for upgraded instances c7c2b6c New selinux interface needed for certmonger directory access c494bd0 Added pki_tomcat_cert_t type and interface to access it edewata (16): c1aa8b2 Enabled authentication for key services. 748605a Fixed synchronization problem in CertificateRepository. 5eab7fe Enabled Tomcat security manager. 9c17ef4 Refactored GetDomainXML servlet. 5bb7933 Added REST interface to get domain info. 6359021 Enabled account service for TKS and OCSP. 8687740 Added conditions for security domain REST service. 7ec6c91 Fixed error handling in RetrieveModificationsTask. 2d3d561 Fixed KRA test. c1f9b39 Enabled realm authentication for certificate requests. 1723a2e Added REST account service. 98ad9c1 Added PKIPrincipal. 4300459 Added PKIConnection. 8973480 Refactored GetCookie servlet. 168d954 Enabled authentication for security domain REST interface. 212ab82 Return to d9 behavior for RetrieveModificationsTask mharmsen (2): a957a3d Allow a PKI instance to be installed/configured independently 8d77b52 Removal of version numbers from jar file names