From WilliamC.Elliott at s-itsolutions.at Wed Mar 2 13:56:16 2011 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Wed, 2 Mar 2011 13:56:16 +0000 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> <4CC89770.1050504@x-zone.org> <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> Message-ID: <85C87A9995875247B2DD471950E0AE4D013EF0@M0181.s-mxs.net> Hi, We seem to have a similar or the same problem as was described in October 2010. I couldn't find any resolution to the problem in the archives. Description of our problem: In Dogtag, addition of CDP extension in enrollment profile corrupts request. Where it does work: RHEL5(x64)/CS 8.0/java 1.6.0_21-b06 --------------------------------------------------- In the profile the following entry adds the extension: policyset.userCertSet.10.constraint.class_id=noConstraintImpl policyset.userCertSet.10.constraint.name=No Constraint policyset.userCertSet.10.default.class_id=crlDistributionPointsExtDefaultImpl policyset.userCertSet.10.default.name=CRL Distribution Points Extension Default policyset.userCertSet.10.default.params.crlDistPointsCritical=false policyset.userCertSet.10.default.params.crlDistPointsEnable_0=true policyset.userCertSet.10.default.params.crlDistPointsIssuerName_0= policyset.userCertSet.10.default.params.crlDistPointsIssuerType_0= policyset.userCertSet.10.default.params.crlDistPointsPointName_0=http://publish.net/crl/foobar/MasterCRL.crl policyset.userCertSet.10.default.params.crlDistPointsPointType_0=URIName policyset.userCertSet.10.default.params.crlDistPointsReasons_0= After "submit" is pushed during enrollment, the following appears in the debug log: [02/Mar/2011:13:34:33][http-9180-Processor19]: EnrollProfile certInfo : [ Version: V3 Subject: UID=test 99 Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 Key: algorithm = RSA, unparsed keybits = ... blahh blahh ... Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthInfoAccess [ (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] Extension[2] = ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Non_repudiation Key_Encipherment ] Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test99 at domain.net]] Extension[5] = CRLDistributionPoints ] The request is approved normally and the extension appears in the certificate: Identifier: CRL Distribution Points - 2.5.29.31 Critical: no Number of Points: 1 Point 0 Distribution Point: [URIName: http://publish.net/crl/foobar/MasterCRL.crl] Where it doesn't work: RHEL5(x64)/Dogtag - pki-ca-1.3.6-1.el5/java(1.6.0_21-b06 and 1.6.0_24-b07) ------------------------------------------------------------------------------------------------- Here, a failure appears already in the debug log after submitting the request: Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthInfoAccess [ (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] Extension[2] = ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Non_repudiation Key_Encipherment ] Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test100 at domain.net]] Extension[5] = ObjectId: 2.5.29.31 Criticality=false Extension unknown: DER encoded OCTET string = 04 44 30 42 30 40 A0 3E A0 3C 86 3A 68 74 74 70 3A 2F 2F 70 75 62 6C 69 73 68 2E 70 6B 69 2E 65 72 73 74 65 2D 67 72 6F 75 70 2E 6E 65 74 2F 63 72 6C 2F 70 69 6C 6F 74 2F 4D 61 73 74 65 72 43 52 4C 2E 63 72 6C ] NOTE: Extension[5]'s OID isn't recognized -- "Extension unknown"?? Then during approval, the java error appears: 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. --------------------------------------------------------------------------------------- It doesn't depend on the java version - two versions result in the same error. addition of the (semi-documented?) parameter "crlDistPointsNum=1" does not fix the problem. Any ideas what the problem could be are greatly appreciated. We can't be the only ones with a CDP in the certificates. Could anyone show me a working profile? thanks in advance, Bill -----Original Message----- From: Elliott William C OSS sIT Sent: Montag, 28. Februar 2011 15:06 To: pki-users at redhat.com Subject: RE: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] Hallo, I have exactly the same problem described in October in the Pki-users mailing list. In the list, there is no resolution. Was someone able to work around the problem? We are running Dogtag on RHEL5 64-bit. The beautiful thing is, the profile works in RH CS 8.0, but throws the java error with Dogtag. The java is slightly newer on the Dogtag system: 1.6.0_24 (where the error occurs) vs. 1.6.0_21 on the CS 8.0. Dogtag version is pki-common-1.3.8-1.el5. Any Ideas? Thanks in advance, Bill -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of sean.veale at gdc4s.com Sent: Freitag, 29. Oktober 2010 15:21 To: fdh at x-zone.org Cc: pki-users at redhat.com Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] 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 > _______________________________________________ Pki-users mailing list Pki-users at redhat.com https://www.redhat.com/mailman/listinfo/pki-users From jmagne at redhat.com Wed Mar 2 17:59:34 2011 From: jmagne at redhat.com (Jack Magne) Date: Wed, 02 Mar 2011 09:59:34 -0800 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error In-Reply-To: <85C87A9995875247B2DD471950E0AE4D013EF0@M0181.s-mxs.net> References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> <4CC89770.1050504@x-zone.org> <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> <85C87A9995875247B2DD471950E0AE4D013EF0@M0181.s-mxs.net> Message-ID: <4D6E8586.7090606@redhat.com> Hi: Having looked at this , I believe that this is the same issue as the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=639082 The little code patch in the bug indicates that it is a matter of identifying the extension to the system. If this is in fact the same problem, this fix is available in the current code and is slated for an upcoming release. On 03/02/2011 05:56 AM, Elliott William C OSS sIT wrote: > Hi, > > We seem to have a similar or the same problem as was described in October 2010. I couldn't find any resolution to the problem in the archives. > > > Description of our problem: > In Dogtag, addition of CDP extension in enrollment profile corrupts request. > > Where it does work: RHEL5(x64)/CS 8.0/java 1.6.0_21-b06 > --------------------------------------------------- > > In the profile the following entry adds the extension: > > policyset.userCertSet.10.constraint.class_id=noConstraintImpl > policyset.userCertSet.10.constraint.name=No Constraint > policyset.userCertSet.10.default.class_id=crlDistributionPointsExtDefaultImpl > policyset.userCertSet.10.default.name=CRL Distribution Points Extension Default > policyset.userCertSet.10.default.params.crlDistPointsCritical=false > policyset.userCertSet.10.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.10.default.params.crlDistPointsIssuerName_0= > policyset.userCertSet.10.default.params.crlDistPointsIssuerType_0= > policyset.userCertSet.10.default.params.crlDistPointsPointName_0=http://publish.net/crl/foobar/MasterCRL.crl > policyset.userCertSet.10.default.params.crlDistPointsPointType_0=URIName > policyset.userCertSet.10.default.params.crlDistPointsReasons_0= > > After "submit" is pushed during enrollment, the following appears in the debug log: > > [02/Mar/2011:13:34:33][http-9180-Processor19]: EnrollProfile certInfo : [ > Version: V3 > Subject: UID=test 99 > Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 > > Key: algorithm = RSA, unparsed keybits = > ... > blahh blahh > ... > Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false > AuthInfoAccess [ > (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] > Extension[2] = ObjectId: 2.5.29.15 Criticality=true > KeyUsage [ > DigitalSignature > Non_repudiation > Key_Encipherment > ] > Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false > SubjectAlternativeName [ > [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test99 at domain.net]] > Extension[5] = CRLDistributionPoints > ] > > The request is approved normally and the extension appears in the certificate: > > Identifier: CRL Distribution Points - 2.5.29.31 > Critical: no > Number of Points: 1 > Point 0 > Distribution Point: [URIName: http://publish.net/crl/foobar/MasterCRL.crl] > > Where it doesn't work: RHEL5(x64)/Dogtag - pki-ca-1.3.6-1.el5/java(1.6.0_21-b06 and 1.6.0_24-b07) > ------------------------------------------------------------------------------------------------- > > Here, a failure appears already in the debug log after submitting the request: > > Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false > AuthInfoAccess [ > (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] > Extension[2] = ObjectId: 2.5.29.15 Criticality=true > KeyUsage [ > DigitalSignature > Non_repudiation > Key_Encipherment > ] > Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false > SubjectAlternativeName [ > [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test100 at domain.net]] > Extension[5] = ObjectId: 2.5.29.31 Criticality=false > Extension unknown: DER encoded OCTET string = > 04 44 30 42 30 40 A0 3E A0 3C 86 3A 68 74 74 70 3A 2F 2F 70 > 75 62 6C 69 73 68 2E 70 6B 69 2E 65 72 73 74 65 2D 67 72 6F > 75 70 2E 6E 65 74 2F 63 72 6C 2F 70 69 6C 6F 74 2F 4D 61 73 > 74 65 72 43 52 4C 2E 63 72 6C > > ] > > NOTE: Extension[5]'s OID isn't recognized -- "Extension unknown"?? > > Then during approval, the java error appears: > > 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. > > --------------------------------------------------------------------------------------- > > It doesn't depend on the java version - two versions result in the same error. > addition of the (semi-documented?) parameter "crlDistPointsNum=1" does not fix the problem. > > Any ideas what the problem could be are greatly appreciated. We can't be the only ones with a CDP in the certificates. > Could anyone show me a working profile? > > thanks in advance, > Bill > > -----Original Message----- > From: Elliott William C OSS sIT > Sent: Montag, 28. Februar 2011 15:06 > To: pki-users at redhat.com > Subject: RE: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] > > Hallo, > > I have exactly the same problem described in October in the Pki-users mailing list. > In the list, there is no resolution. Was someone able to work around the problem? > > We are running Dogtag on RHEL5 64-bit. > The beautiful thing is, the profile works in RH CS 8.0, but throws the java error with Dogtag. > > The java is slightly newer on the Dogtag system: 1.6.0_24 (where the error occurs) vs. 1.6.0_21 on the CS 8.0. > Dogtag version is pki-common-1.3.8-1.el5. > > Any Ideas? > > Thanks in advance, > Bill > > > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of sean.veale at gdc4s.com > Sent: Freitag, 29. Oktober 2010 15:21 > To: fdh at x-zone.org > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] > > 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 >> >> > > _______________________________________________ > 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 WilliamC.Elliott at s-itsolutions.at Thu Mar 3 08:06:50 2011 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Thu, 3 Mar 2011 08:06:50 +0000 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error In-Reply-To: <4D6E8586.7090606@redhat.com> References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> <4CC89770.1050504@x-zone.org> <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> <85C87A9995875247B2DD471950E0AE4D013EF0@M0181.s-mxs.net> <4D6E8586.7090606@redhat.com> Message-ID: <85C87A9995875247B2DD471950E0AE4D0140AA@M0181.s-mxs.net> Hi, That sounds very promising. Thanks for the tip! -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Jack Magne Sent: Mittwoch, 02. M?rz 2011 19:00 To: pki-users at redhat.com Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] Hi: Having looked at this , I believe that this is the same issue as the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=639082 The little code patch in the bug indicates that it is a matter of identifying the extension to the system. If this is in fact the same problem, this fix is available in the current code and is slated for an upcoming release. On 03/02/2011 05:56 AM, Elliott William C OSS sIT wrote: > Hi, > > We seem to have a similar or the same problem as was described in October 2010. I couldn't find any resolution to the problem in the archives. > > > Description of our problem: > In Dogtag, addition of CDP extension in enrollment profile corrupts request. > > Where it does work: RHEL5(x64)/CS 8.0/java 1.6.0_21-b06 > --------------------------------------------------- > > In the profile the following entry adds the extension: > > policyset.userCertSet.10.constraint.class_id=noConstraintImpl > policyset.userCertSet.10.constraint.name=No Constraint > policyset.userCertSet.10.default.class_id=crlDistributionPointsExtDefaultImpl > policyset.userCertSet.10.default.name=CRL Distribution Points Extension Default > policyset.userCertSet.10.default.params.crlDistPointsCritical=false > policyset.userCertSet.10.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.10.default.params.crlDistPointsIssuerName_0= > policyset.userCertSet.10.default.params.crlDistPointsIssuerType_0= > policyset.userCertSet.10.default.params.crlDistPointsPointName_0=http://publish.net/crl/foobar/MasterCRL.crl > policyset.userCertSet.10.default.params.crlDistPointsPointType_0=URIName > policyset.userCertSet.10.default.params.crlDistPointsReasons_0= > > After "submit" is pushed during enrollment, the following appears in the debug log: > > [02/Mar/2011:13:34:33][http-9180-Processor19]: EnrollProfile certInfo : [ > Version: V3 > Subject: UID=test 99 > Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 > > Key: algorithm = RSA, unparsed keybits = > ... > blahh blahh > ... > Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false > AuthInfoAccess [ > (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] > Extension[2] = ObjectId: 2.5.29.15 Criticality=true > KeyUsage [ > DigitalSignature > Non_repudiation > Key_Encipherment > ] > Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false > SubjectAlternativeName [ > [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test99 at domain.net]] > Extension[5] = CRLDistributionPoints > ] > > The request is approved normally and the extension appears in the certificate: > > Identifier: CRL Distribution Points - 2.5.29.31 > Critical: no > Number of Points: 1 > Point 0 > Distribution Point: [URIName: http://publish.net/crl/foobar/MasterCRL.crl] > > Where it doesn't work: RHEL5(x64)/Dogtag - pki-ca-1.3.6-1.el5/java(1.6.0_21-b06 and 1.6.0_24-b07) > ------------------------------------------------------------------------------------------------- > > Here, a failure appears already in the debug log after submitting the request: > > Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false > AuthInfoAccess [ > (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] > Extension[2] = ObjectId: 2.5.29.15 Criticality=true > KeyUsage [ > DigitalSignature > Non_repudiation > Key_Encipherment > ] > Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false > SubjectAlternativeName [ > [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test100 at domain.net]] > Extension[5] = ObjectId: 2.5.29.31 Criticality=false > Extension unknown: DER encoded OCTET string = > 04 44 30 42 30 40 A0 3E A0 3C 86 3A 68 74 74 70 3A 2F 2F 70 > 75 62 6C 69 73 68 2E 70 6B 69 2E 65 72 73 74 65 2D 67 72 6F > 75 70 2E 6E 65 74 2F 63 72 6C 2F 70 69 6C 6F 74 2F 4D 61 73 > 74 65 72 43 52 4C 2E 63 72 6C > > ] > > NOTE: Extension[5]'s OID isn't recognized -- "Extension unknown"?? > > Then during approval, the java error appears: > > 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. > > --------------------------------------------------------------------------------------- > > It doesn't depend on the java version - two versions result in the same error. > addition of the (semi-documented?) parameter "crlDistPointsNum=1" does not fix the problem. > > Any ideas what the problem could be are greatly appreciated. We can't be the only ones with a CDP in the certificates. > Could anyone show me a working profile? > > thanks in advance, > Bill > > -----Original Message----- > From: Elliott William C OSS sIT > Sent: Montag, 28. Februar 2011 15:06 > To: pki-users at redhat.com > Subject: RE: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] > > Hallo, > > I have exactly the same problem described in October in the Pki-users mailing list. > In the list, there is no resolution. Was someone able to work around the problem? > > We are running Dogtag on RHEL5 64-bit. > The beautiful thing is, the profile works in RH CS 8.0, but throws the java error with Dogtag. > > The java is slightly newer on the Dogtag system: 1.6.0_24 (where the error occurs) vs. 1.6.0_21 on the CS 8.0. > Dogtag version is pki-common-1.3.8-1.el5. > > Any Ideas? > > Thanks in advance, > Bill > > > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of sean.veale at gdc4s.com > Sent: Freitag, 29. Oktober 2010 15:21 > To: fdh at x-zone.org > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] > > 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 >> >> > > _______________________________________________ > 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 From WilliamC.Elliott at s-itsolutions.at Thu Mar 3 13:20:35 2011 From: WilliamC.Elliott at s-itsolutions.at (Elliott William C OSS sIT) Date: Thu, 3 Mar 2011 13:20:35 +0000 Subject: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error References: <4CC15FCC.6030903@x-zone.org> <5E904A528F23FA469961CECAC5F4178702C6E5C1@NDHMC4SXCH.gdc4s.com> <4CC89770.1050504@x-zone.org> <5E904A528F23FA469961CECAC5F4178702CBA2B2@NDHMC4SXCH.gdc4s.com> <85C87A9995875247B2DD471950E0AE4D013EF0@M0181.s-mxs.net> <4D6E8586.7090606@redhat.com> Message-ID: <85C87A9995875247B2DD471950E0AE4D014168@M0181.s-mxs.net> Last post: The patch worked - we patched the file in the source rpm, rebuilt the jar file. - Super! Thanks for the help! -----Original Message----- From: Elliott William C OSS sIT Sent: Donnerstag, 03. M?rz 2011 09:07 To: pki-users at redhat.com Subject: RE: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] Hi, That sounds very promising. Thanks for the tip! -----Original Message----- From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of Jack Magne Sent: Mittwoch, 02. M?rz 2011 19:00 To: pki-users at redhat.com Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] Hi: Having looked at this , I believe that this is the same issue as the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=639082 The little code patch in the bug indicates that it is a matter of identifying the extension to the system. If this is in fact the same problem, this fix is available in the current code and is slated for an upcoming release. On 03/02/2011 05:56 AM, Elliott William C OSS sIT wrote: > Hi, > > We seem to have a similar or the same problem as was described in October 2010. I couldn't find any resolution to the problem in the archives. > > > Description of our problem: > In Dogtag, addition of CDP extension in enrollment profile corrupts request. > > Where it does work: RHEL5(x64)/CS 8.0/java 1.6.0_21-b06 > --------------------------------------------------- > > In the profile the following entry adds the extension: > > policyset.userCertSet.10.constraint.class_id=noConstraintImpl > policyset.userCertSet.10.constraint.name=No Constraint > policyset.userCertSet.10.default.class_id=crlDistributionPointsExtDefaultImpl > policyset.userCertSet.10.default.name=CRL Distribution Points Extension Default > policyset.userCertSet.10.default.params.crlDistPointsCritical=false > policyset.userCertSet.10.default.params.crlDistPointsEnable_0=true > policyset.userCertSet.10.default.params.crlDistPointsIssuerName_0= > policyset.userCertSet.10.default.params.crlDistPointsIssuerType_0= > policyset.userCertSet.10.default.params.crlDistPointsPointName_0=http://publish.net/crl/foobar/MasterCRL.crl > policyset.userCertSet.10.default.params.crlDistPointsPointType_0=URIName > policyset.userCertSet.10.default.params.crlDistPointsReasons_0= > > After "submit" is pushed during enrollment, the following appears in the debug log: > > [02/Mar/2011:13:34:33][http-9180-Processor19]: EnrollProfile certInfo : [ > Version: V3 > Subject: UID=test 99 > Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 > > Key: algorithm = RSA, unparsed keybits = > ... > blahh blahh > ... > Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false > AuthInfoAccess [ > (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] > Extension[2] = ObjectId: 2.5.29.15 Criticality=true > KeyUsage [ > DigitalSignature > Non_repudiation > Key_Encipherment > ] > Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false > SubjectAlternativeName [ > [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test99 at domain.net]] > Extension[5] = CRLDistributionPoints > ] > > The request is approved normally and the extension appears in the certificate: > > Identifier: CRL Distribution Points - 2.5.29.31 > Critical: no > Number of Points: 1 > Point 0 > Distribution Point: [URIName: http://publish.net/crl/foobar/MasterCRL.crl] > > Where it doesn't work: RHEL5(x64)/Dogtag - pki-ca-1.3.6-1.el5/java(1.6.0_21-b06 and 1.6.0_24-b07) > ------------------------------------------------------------------------------------------------- > > Here, a failure appears already in the debug log after submitting the request: > > Extension[1] = ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false > AuthInfoAccess [ > (0) 1.3.6.1.5.5.7.48.1 URIName: http://test.net:9180/ca/ocsp] > Extension[2] = ObjectId: 2.5.29.15 Criticality=true > KeyUsage [ > DigitalSignature > Non_repudiation > Key_Encipherment > ] > Extension[3] = oid=2.5.29.37 val=48 22 6 8 43 6 1 5 5 7 3 2 6 10 43 6 1 4 1 -126 55 20 2 2 Extension[4] = ObjectId: 2.5.29.17 Criticality=false > SubjectAlternativeName [ > [OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,test100 at domain.net]] > Extension[5] = ObjectId: 2.5.29.31 Criticality=false > Extension unknown: DER encoded OCTET string = > 04 44 30 42 30 40 A0 3E A0 3C 86 3A 68 74 74 70 3A 2F 2F 70 > 75 62 6C 69 73 68 2E 70 6B 69 2E 65 72 73 74 65 2D 67 72 6F > 75 70 2E 6E 65 74 2F 63 72 6C 2F 70 69 6C 6F 74 2F 4D 61 73 > 74 65 72 43 52 4C 2E 63 72 6C > > ] > > NOTE: Extension[5]'s OID isn't recognized -- "Extension unknown"?? > > Then during approval, the java error appears: > > 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. > > --------------------------------------------------------------------------------------- > > It doesn't depend on the java version - two versions result in the same error. > addition of the (semi-documented?) parameter "crlDistPointsNum=1" does not fix the problem. > > Any ideas what the problem could be are greatly appreciated. We can't be the only ones with a CDP in the certificates. > Could anyone show me a working profile? > > thanks in advance, > Bill > > -----Original Message----- > From: Elliott William C OSS sIT > Sent: Montag, 28. Februar 2011 15:06 > To: pki-users at redhat.com > Subject: RE: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] > > Hallo, > > I have exactly the same problem described in October in the Pki-users mailing list. > In the list, there is no resolution. Was someone able to work around the problem? > > We are running Dogtag on RHEL5 64-bit. > The beautiful thing is, the profile works in RH CS 8.0, but throws the java error with Dogtag. > > The java is slightly newer on the Dogtag system: 1.6.0_24 (where the error occurs) vs. 1.6.0_21 on the CS 8.0. > Dogtag version is pki-common-1.3.8-1.el5. > > Any Ideas? > > Thanks in advance, > Bill > > > -----Original Message----- > From: pki-users-bounces at redhat.com [mailto:pki-users-bounces at redhat.com] On Behalf Of sean.veale at gdc4s.com > Sent: Freitag, 29. Oktober 2010 15:21 > To: fdh at x-zone.org > Cc: pki-users at redhat.com > Subject: Re: [Pki-users] DogTAG PKI - crlDistributionPoints cert profile: Type_0 : URIName error [bayes][heur] > > 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 >> >> > > _______________________________________________ > 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 From mrb137 at gmail.com Wed Mar 16 18:59:55 2011 From: mrb137 at gmail.com (Michael Brown) Date: Wed, 16 Mar 2011 14:59:55 -0400 Subject: [Pki-users] pkicreate issue - missing Catalina link? Message-ID: pki-users I am attempting a load of Dogtag 1.3 on Fedora 14. When attempting to create a CA instance with 'pkicreate' I get this error at the end of pkicreate - ==== PKI instance creation completed ... Stopping idca-1: process already stopped ============================================================ Starting idca-1: /etc/init.d/pki-cad: line 868: /usr/share/tomcat5/bin/relink: No such file or directory /usr/bin/build-classpath: error: Could not find mx4j/mx4j-impl Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found /usr/bin/build-classpath: error: Could not find mx4j/mx4j-jmx Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found [ OK ] idca-1 (pid 30014) is running ... 'idca-1' must still be CONFIGURED! (see /var/log/idca-1-install.log) Before proceeding with the configuration, make sure the firewall settings of this machine permit proper access to this subsystem. ==== There is nothing in /var/log/idca-1-install.log corresponding to this error. After running pkicreate I cannot access the console to configure the CA. When removing the instance with 'pkiremove' I see a corresponding error - Stopping idca-1: /usr/bin/build-classpath: error: Could not find mx4j/mx4j-impl Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found /usr/bin/build-classpath: error: Could not find mx4j/mx4j-jmx Java extension for this JVM /usr/bin/build-classpath: error: Some specified jars were not found Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/catalina/startup/Bootstrap Caused by: java.lang.ClassNotFoundException: org.apache.catalina.startup.Bootstrap at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) Could not find the main class: org.apache.catalina.startup.Bootstrap. Program will exit. [ OK ] Running 'Alternatives --display java' indicates the system is pointing to openjdk-1.6.0 correctly Looking on the Fedora Dogtag site I note that there was what looks like a similar issue that was fixed referenced here - http://pki.fedoraproject.org/wiki/PKI_Known_Issues#PKI_Subsystem_Installation that indicates a missing symbolic link. Has anyone seen this issue with Dogtag 1.3/Fedora 14 before? Any suggestions? From msauton at redhat.com Wed Mar 16 19:19:40 2011 From: msauton at redhat.com (Marc Sauton) Date: Wed, 16 Mar 2011 12:19:40 -0700 Subject: [Pki-users] pkicreate issue - missing Catalina link? In-Reply-To: References: Message-ID: <4D810D4C.30904@redhat.com> A known good combination is F13 with tomcat 5 and tomcatjss 1.2 for Dogtag 1.3 I believe F14 is more for Dogtag 2.0 / pki-ca 9.0 along with tomcat 6 and tomcatjss 2.0 M. On 03/16/2011 11:59 AM, Michael Brown wrote: > pki-users > > I am attempting a load of Dogtag 1.3 on Fedora 14. When attempting to > create a CA instance with 'pkicreate' I get this error at the end of > pkicreate - > > ==== > > PKI instance creation completed ... > > Stopping idca-1: > process already stopped > > ============================================================ > > Starting idca-1: /etc/init.d/pki-cad: line 868: > /usr/share/tomcat5/bin/relink: No such file or directory > /usr/bin/build-classpath: error: Could not find mx4j/mx4j-impl Java > extension for this JVM > /usr/bin/build-classpath: error: Some specified jars were not found > /usr/bin/build-classpath: error: Could not find mx4j/mx4j-jmx Java > extension for this JVM > /usr/bin/build-classpath: error: Some specified jars were not found > [ OK ] > > idca-1 (pid 30014) is running ... > > 'idca-1' must still be CONFIGURED! > (see /var/log/idca-1-install.log) > > Before proceeding with the configuration, make sure > the firewall settings of this machine permit proper > access to this subsystem. > > ==== > > There is nothing in /var/log/idca-1-install.log corresponding to this > error. After running pkicreate I cannot access the console to > configure the CA. > > When removing the instance with 'pkiremove' I see a corresponding error - > > Stopping idca-1: /usr/bin/build-classpath: error: Could not find > mx4j/mx4j-impl Java extension for this JVM > /usr/bin/build-classpath: error: Some specified jars were not found > /usr/bin/build-classpath: error: Could not find mx4j/mx4j-jmx Java > extension for this JVM > /usr/bin/build-classpath: error: Some specified jars were not found > Exception in thread "main" java.lang.NoClassDefFoundError: > org/apache/catalina/startup/Bootstrap > Caused by: java.lang.ClassNotFoundException: > org.apache.catalina.startup.Bootstrap > at java.net.URLClassLoader$1.run(URLClassLoader.java:217) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:205) > at java.lang.ClassLoader.loadClass(ClassLoader.java:321) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) > at java.lang.ClassLoader.loadClass(ClassLoader.java:266) > Could not find the main class: org.apache.catalina.startup.Bootstrap. > Program will exit. > [ OK ] > > Running 'Alternatives --display java' indicates the system is pointing > to openjdk-1.6.0 correctly > > Looking on the Fedora Dogtag site I note that there was what looks > like a similar issue that was fixed referenced here - > > http://pki.fedoraproject.org/wiki/PKI_Known_Issues#PKI_Subsystem_Installation > > that indicates a missing symbolic link. > > Has anyone seen this issue with Dogtag 1.3/Fedora 14 before? Any suggestions? > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users