Bug 1462308 - cert-show CLI: change "Status" terminology to refer to "Revocation status"
cert-show CLI: change "Status" terminology to refer to "Revocation status"
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: RHCS Maintainers
Asha Akkiangady
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-16 13:13 EDT by Geetika Kapoor
Modified: 2017-10-31 17:53 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Geetika Kapoor 2017-06-16 13:13:52 EDT
Description of problem:

Expired certificates are not moving to CRL .

Setup:
------

1. Create a certificate using CaUserCert.Expire the certificate.
2. Now since this certificate is expired it should be visible as "Expired" in CA Agent page.

Issue 1 : Even if we check "show expired certs" for a CRL issuing point from console,Expired certificates are not shown.

Issue 2: If we have two certificates :
0x35 -- Revoked 
0X36 -- Expired

On CA Agent page --> List certificate  
Lowest serial number 	0x36	(leave blank for no lower limit)
Highest serial number 	0x38	(leave blank for no upper limit)

(check)Do not show certificates that have been revoked
(check)Do not show certificates that have expired or are not yet valid

Output:
Serial number 	Status 	Subject name
0x34 	valid 	
UID=revokecert4





Version-Release number of selected component (if applicable):
10.1.4_8

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Fraser Tweedale 2017-06-22 21:04:07 EDT
Geetika, what procedure is being used to "Expire the certificate"?
Comment 3 Geetika Kapoor 2017-06-23 04:32:14 EDT
Hi ,
in caCertUser.cfg, I have replace 180 days with 1 day and generate a cert.
Example: My current date is 22-June-2017 so certificate will be valid for 23-June-2017.
Then i change my system date to 23-June-2017 23:58 pm so after 2 mins it will be 24 June and certificate should be expired.
So now I take this certificate convert in p12 and import in my browser.This certificate was considered as invalid(browser detects it) but on CA agent page status is shown as valid.

procedure 2: Set time from days to minute in caUserCert.cfg.In that case certificate will be valid for 1 minute only.

I have setup with me if you wanted to have a look
Comment 4 Fraser Tweedale 2017-06-25 21:18:51 EDT
Geetika, thanks for additional info.

With the "1 day" profile it really means "24 hours", so if you issue a cert
at 23:58 it will expire at 23:58 on the following day, not two minutes later when the day ticks over.

Anyhow I will do a bit of testing around this and see what I can find out.
Comment 5 Fraser Tweedale 2017-06-27 03:01:22 EDT
Additional info following investigation:

0. The default CRL refresh interval is 15 minutes.  Therefore there
   can be up to a 15 minute wait after revoking a cert before it
   appears on the CRL.

1. Expired certs do not appear on CRLs - only revoked certs.
   Even a revoked cert is removed from the CRL after its notAfter
   date is passed.

2. The CertStatusUpdateTask which runs every 10 minutes is responsible for
   detecting expired certs and updating their status in the database.
   Until this task is run, an expired cert may appear in a search
   result that is supposed to exclude expired certs.

3. The listing in the Web UI of a cert as "valid" shows whether it
   was revoked or not, and does not indicate whether it is within
   the validity period.  Confusing indeed.  Arguably a UX bug that
   should be fixed.

Geetika, besides the confusing UI signal discussed at (3), and the
caveats of (0) (1) and (2), do you observe any other dubious behaviour?
Comment 6 Geetika Kapoor 2017-06-27 04:39:38 EDT
I have my responses inline. Thanks Fraser for looking into it.

0. The default CRL refresh interval is 15 minutes.  Therefore there
   can be up to a 15 minute wait after revoking a cert before it
   appears on the CRL.
-- Default CRL update is 240 minutes.I have set it to 2 minutes for my testing.
I have opened one more linked bugzilla were i have mentioned few more observations.

   https://bugzilla.redhat.com/show_bug.cgi?id=1462291

1. Expired certs do not appear on CRLs - only revoked certs.
   Even a revoked cert is removed from the CRL after its notAfter
   date is passed.

-- That's true only revoked are coming even after you set the option to send expire certs also in CRL.

2. The CertStatusUpdateTask which runs every 10 minutes is responsible for
   detecting expired certs and updating their status in the database.
   Until this task is run, an expired cert may appear in a search
   result that is supposed to exclude expired certs.

-- For me even after 10 days I have an expired cert which never comes up in CRL and OCSp still detecting it as good certificate.

3. The listing in the Web UI of a cert as "valid" shows whether it
   was revoked or not, and does not indicate whether it is within
   the validity period.  Confusing indeed.  Arguably a UX bug that
   should be fixed.

Geetika, besides the confusing UI signal discussed at (3), and the
caveats of (0) (1) and (2), do you observe any other dubious behaviour?
Comment 7 Geetika Kapoor 2017-06-27 04:42:18 EDT
1. Expired certs do not appear on CRLs - only revoked certs.
   Even a revoked cert is removed from the CRL after its notAfter
   date is passed.

This happens basically because after "notAfter" date that certificate is expired and currently CRL is not displaying any expired certs.So that's one issue is CRL is not able to handle expired certs even if we are supporting that option in CS.cfg and pkiconsole.
Comment 8 Endi Sukma Dewata 2017-06-28 12:21:43 EDT
Just FYI, see also this ticket: https://pagure.io/dogtagpki/issue/2769

The cert status in the cert record is not that reliable since it depends on the server's system date and the update interval.
Comment 9 Christina Fu 2017-07-03 12:46:29 EDT
Geetika, I may be misunderstanding your description, but it sounds like you are expecting an expired cert to go into the CRL.  If that's what you are saying, that is incorrect.  Only certs that are revoked will ever go into the CRL.  When it's expired, it gets removed by default.

There is an option in the CS.cfg to allow for a revoked certificate that also happens to have expired to be in the CRL. 

The option is
ca.crl.MasterCRL.includeExpiredCerts
which is default to false

In other words, to make it clear, the CRL can only contain the following:
* Revoked non-expired certificates (absolute)
* Revoked expired certificate (optional)

Of course if you happen to run into what Endi mentioned (2769) then it's a bug.
Comment 10 Matthew Harmsen 2017-07-05 17:38:30 EDT
During TRIAGE, moved this back from 7.5 ==> 7.4.z for resolution
Comment 11 Matthew Harmsen 2017-07-05 17:40:22 EDT
(In reply to Christina Fu from comment #9)
> Geetika, I may be misunderstanding your description, but it sounds like you
> are expecting an expired cert to go into the CRL.  If that's what you are
> saying, that is incorrect.  Only certs that are revoked will ever go into
> the CRL.  When it's expired, it gets removed by default.
> 
> There is an option in the CS.cfg to allow for a revoked certificate that
> also happens to have expired to be in the CRL. 
> 
> The option is
> ca.crl.MasterCRL.includeExpiredCerts
> which is default to false
> 
> In other words, to make it clear, the CRL can only contain the following:
> * Revoked non-expired certificates (absolute)
> * Revoked expired certificate (optional)
> 
> Of course if you happen to run into what Endi mentioned (2769) then it's a
> bug.
Comment 12 Geetika Kapoor 2017-07-10 05:16:35 EDT
Thanks Christina. Your explanation helps in better understanding on my first use case (you resolved that part.:)).
I have 2 more use cases where I think behavior is not right but it would be great if you can look into that too.

Use Case 2:

1. I have a certificate generated for one minute.So it should be expired and status should be returned correctly.

Time when i run the command:
----------------------------

date
Mon Jul 10 22:46:52 EDT 2017

Cli output:

pki  -d nssdb -p 25080 ca-cert-show  0x5b6e2e1
-----------------------
Certificate "0x5b6e2e1"
-----------------------
  Serial Number: 0x5b6e2e1
  Issuer: CN=CA Signing Certificate,OU=pki-RootCA-CMC3,O=Example-Test-rhel-fips
  Subject: UID=revoke_expire_1
  Status: VALID
  Not Before: Mon Jul 10 22:31:42 EDT 2017
  Not After: Mon Jul 10 22:32:42 EDT 2017

So this certificate status is still "VALID" even if it is expired.

I am not sure if this is right behavior?

Use Case 3: Can i revoke my expired certificate? Right now we are able to revoke an expired certificate.
Comment 13 Geetika Kapoor 2017-07-10 05:47:40 EDT
Use case 3 with detailed steps:
------------------------------
1. Have an expired cert.

[root@pki1 ~]# pki  -d nssdb -p 25080 ca-cert-show  0x5b6e2e1
-----------------------
Certificate "0x5b6e2e1"
-----------------------
  Serial Number: 0x5b6e2e1
  Issuer: CN=CA Signing Certificate,OU=pki-RootCA-CMC3,O=Example-Test-rhel-fips
  Subject: UID=revoke_expire_1
  Status: EXPIRED
  Not Before: Mon Jul 10 22:31:42 EDT 2017
  Not After: Mon Jul 10 22:32:42 EDT 2017

2. Revoke it.

pki  -d nssdb -p 25080 ca-cert-show  0x5b6e2e1
-----------------------
Certificate "0x5b6e2e1"
-----------------------
  Serial Number: 0x5b6e2e1
  Issuer: CN=CA Signing Certificate,OU=pki-RootCA-CMC3,O=Example-Test-rhel-fips
  Subject: UID=revoke_expire_1
  Status: REVOKED
  Not Before: Mon Jul 10 22:31:42 EDT 2017
  Not After: Mon Jul 10 22:32:42 EDT 2017
  Revoked On: Mon Jul 10 23:16:14 EDT 2017
  Revoked By: caadmin


3. Check the status.

pki  -d nssdb -p 25080 ca-cert-show  0x5b6e2e1
-----------------------
Certificate "0x5b6e2e1"
-----------------------
  Serial Number: 0x5b6e2e1
  Issuer: CN=CA Signing Certificate,OU=pki-RootCA-CMC3,O=Example-Test-rhel-fips
  Subject: UID=revoke_expire_1
  Status: VALID
  Not Before: Mon Jul 10 22:31:42 EDT 2017
  Not After: Mon Jul 10 22:32:42 EDT 2017
Comment 14 Fraser Tweedale 2017-07-10 06:24:43 EDT
Hi Geetika,

For use case 2, this is IMO a UI bug.  That field "Status" is indicating whether the certificate is or is not revoked.  So whether it's expired or not is not actually indicated by that field.  There is no problem with the cert itself or how Dogtag treats it internally, just how the information is presented to the user.

But I agree 100%, it is confusing and should be improved.

For use case 3, this is fine, you can revoke an expired certificate.  It will not (in the default configuration) appear on CRLs, but the OCSP responses will change to indicate that the certificate is revoked.
Comment 15 Fraser Tweedale 2017-07-10 07:46:43 EDT
From IRC discussion:

21:44 < ftweedal> gkapoor: the status gets changed properly in the database (after a delay of up to 10 or 15 minutes 
                  for the job to run).  But the CLI program, that field is actually reporting whether it's revoked 
                  (REVOKED) or not (VALID).  So it is confusingly labeled, but the information it shows is correct.
21:45 < ftweedal> i.e. perhaps instead of VALID it should say "NOT REVOKED", and maybe the label should be 
                  "Revocation status" instead of just "status"
21:45 < ftweedal> to avoid confusion
21:45 < gkapoor> okay yea that's would be better
Comment 16 Christina Fu 2017-07-13 21:25:19 EDT
So, per Fraser's response, this bug probably deserves a new description.  Could one of you go ahead and change that?
Comment 17 Fraser Tweedale 2017-07-13 22:14:56 EDT
Changed the ticket summary.  Clarified requirments in
https://bugzilla.redhat.com/show_bug.cgi?id=1462308#c15.
Comment 19 Matthew Harmsen 2017-10-25 13:21:54 EDT
[20171025] - RHEL 7.5 pre-Alpha Offline Triage ==> 7.6
Comment 21 Matthew Harmsen 2017-10-31 17:53:14 EDT
[20171025] - Offline Triage ==> 10.6

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