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://p...
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(a)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(a)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(a)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(a)redhat.com [mailto:pki-users-bounces@redhat.com] On Behalf Of
sean.veale(a)gdc4s.com
Sent: Freitag, 29. Oktober 2010 15:21
To: fdh(a)x-zone.org
Cc: pki-users(a)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(a)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(a)redhat.com
[mailto:pki-users-bounces@redhat.com]
On Behalf Of Frederic d'Huart
Sent: Friday, October 22, 2010 5:56 AM
To: pki-users(a)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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/pki-users
>
_______________________________________________
Pki-users mailing list
Pki-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-users