Bug 441544 - custom profile ignores user supplied validity
custom profile ignores user supplied validity
Status: NEW
Product: Dogtag Certificate System
Classification: Community
Component: Profile (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Christina Fu
Ben Levenson
Depends On:
Blocks: 530474
  Show dependency treegraph
Reported: 2008-04-08 13:43 EDT by David Stutzman
Modified: 2015-01-04 19:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
contents of my custom profile (5.64 KB, text/plain)
2008-04-08 13:44 EDT, David Stutzman
no flags Details
base64 crmf request and asn1dump of the request (7.94 KB, text/plain)
2008-04-08 14:34 EDT, David Stutzman
no flags Details

  None (edit)
Description David Stutzman 2008-04-08 13:43:40 EDT
Description of problem:
I have a custom CMC profile that will take the requested validity period out of
the embedded CRMF request and use that for the validity period on the
certificate.  The user-supplied validity is being ignored and the issued
certificate has a notBefore and notAfter time that is exactly the same and is
the current time.

How reproducible:

Steps to Reproduce:
1. first attachment to the bug is the full contents of my custom profile, it
represents the contents of /var/lib/pki-ca/profiles/ca/caFullCMCUserCert.cfg.
2. Go to end-entity interface and select the profile uses caFullCMCUserCert.cfg,
should be the second one labeled "Signed CMC-Authenticated User Certificate
Enrollment", mouse over it and look at the end of the url for
3. paste in a CMC (attachment 300295 [details]) request with an embedded CRMF containing
validity information and submit it. 
4. Inspect the resulting certificate's notBefore and notAfter times
Actual results:
notBefore = notAfter = current time

Expected results:
notBefore and notAfter = the values from the CRMF request (CRMF contains       
                   UTCTime 03/04/2008 18:06:54 GMT and UTCTime 04/04/2008
18:06:54 GMT)

Additional info:
In the debug log for the CA there is the following exception.  I'm not sure
where else to look for further info:
[08/Apr/2008:13:26:54][http-9443-Processor25]: UserValidityDefault: populate start
[08/Apr/2008:13:26:54][http-9443-Processor25]: UserValidityDefault: populate
java.security.cert.CertificateException: CertificateValidity class type invalid.
[08/Apr/2008:13:26:54][http-9443-Processor25]: UserValidityDefault: populate end

Further down in the log when it shows the TBS cert request it shows the
notBefore and notAfter are the same time:
[08/Apr/2008:13:26:54][http-9443-Processor25]: ValidityConstraint: validate start
[08/Apr/2008:13:26:54][http-9443-Processor25]: ValidityConstraint: millisDiff=0
notAfter=1207675614000 notBefore=1207675614000
[08/Apr/2008:13:26:54][http-9443-Processor25]: ValidityConstraint: long_days: 0
[08/Apr/2008:13:26:54][http-9443-Processor25]: ValidityConstraint: days: 0
[08/Apr/2008:13:26:54][http-9443-Processor25]: ValidityConstraint: validate end
  Validity: [From: Tue Apr 08 13:26:54 EDT 2008,
               To: Tue Apr 08 13:26:54 EDT 2008]

If you go back to the profiles page and select the first "Signed
CMC-Authenticated User Certificate Enrollment" (link ends with
..profileSelect?profileId=caCMCUserCert) and paste in the same request, the cert
will be issued with 180 day validity because that profile has a hardcoded 180
day validity period:
policyset.cmcUserCertSet.2.constraint.name=Validity Constraint
Comment 1 David Stutzman 2008-04-08 13:44:56 EDT
Created attachment 301665 [details]
contents of my custom profile
Comment 2 David Stutzman 2008-04-08 14:34:18 EDT
Created attachment 301684 [details]
base64 crmf request and asn1dump of the request
Comment 6 Nathan Kinder 2012-12-11 11:43:27 EST
Upstream ticket:

Note You need to log in before you can comment on or make changes to this bug.