748122 - Secure against Symantec/Verisign OV certs being issued with excessive validity period (6 years)

Status: RESOLVED WORKSFORME

(CA Program :: CA Certificate Root Program, task)

Description

[Marsh Ray]

Attachment: pfd.phonefactor.net.pem

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120410121533

Steps to reproduce:

The "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0" is said to take effect on July 1. However, surely other contractual agreements and common sense must apply today.

vvvvvvvvvvvvvvvv CABF baseline 1.0
9.4 Validity Period
Certificates issued after the Effective Date MUST have a Validity Period no greater than 60 months.
Except as provided for below, Certificates issued after 1 April 2015 MUST have a Validity Period no greater than
39 months.
Beyond 1 April 2015, CAs MAY continue to issue Certificates with a Validity Period greater than 39 months but not greater than 60 months provided that the CA documents that the Certificate is for a system or software that:
(a) was in use prior to the Effective Date;
(b) is currently in use by either the Applicant or a substantial number of Relying Parties;
(c) fails to operate if the Validity Period is shorter than 60 months;
(d) does not contain known security risks to Relying Parties; and
(e) is difficult to patch or replace without substantial economic outlay.
^^^^^^^^^^^^^^^^ CABF baseline 1.0



Actual results:

Attached is a "smoking gun" cert which Symantec/Verisign has issued with a Validity Period ending 6 years into the future, in clear contravention of the Baseline Requirements. At my company, PhoneFactor, we have been a customer of Verisign for many years. We greatly prefer to have certs with a reasonable expiration period!

Recent events in the world of SSL certs have proven that revocation (whether it is via CRLs or OCSP) is simply not reliable. Mozilla and the other browser vendors had to race out emergency patches when fraudulent certs were issued precisely because attackers have the capability to block revocation updates at the network level and virtually all clients "fail open" in such a configuration.

It appears that Symantec/Verisign is planning to revoke these certs early whenever customers decline to "renew" them before the 6 year period is up (I can't imagine how big that CRL is going to get). No one with a clue about PKI security would believe that a revoked cert provides equivalent security from misuse as a naturally-expired cert.

I am bugging this here because Mozilla products include this CA in its trusted root store, while this CA appears to be operating outside the bounds of good security practices. Mozilla was very helpful in the Trustwave affair. I will also copy the CA/B Forum via their public email address.  

This bug may or may not represent a code change (for example, NSS could distrust entity certs according to the Baseline Requirements regardless of the stated validity period).

Here is a transcript of Tommy (in our Operations department) attempting to renew one of our certs with the usual 2-year validity period:

Customer Chat
Chat Transcript
Please wait while we find a representative to assist you.
You have been connected to Melissa.
Melissa:  Hello. How may I assist you?
Melissa:  Do you have an Order Number or Common Name I can reference?
Tommy:  I already entered it, then closed that window
Tommy:  the common name is pfd.phonefactor.net
Melissa:  Hi Tommy, how can I help?
Tommy:  When we look at the cert in a browser it says the expiration date is in 2018, but I only paid for a 2 year cert.
Tommy:  Can you explain why the expiration doesn't say 2014?
Melissa:  That is because you have one of the express renewal certificates. As long as you process your renewal payment you will not need to install again until 2018.
Melissa:  So the validity shows longer to anticipate that.
Tommy:  does it have anything to do with cert revocation?
Melissa:  If you revoke the certificate or not pay the renewal it will show invalid in the CRL (certificate revocation list) however as long as it is paid for in 2014 and not revoked manually it will be good
Tommy:  we cannot afford for that cert to be revoked, ever, based on our human error ( forgetting to renew or something ) ... hmmm
Tommy:  one sec, I'm talking something over with someone on my side.
Melissa:  Ok
Tommy:  sorry, should only be another moment or so
Melissa:  Sure.
Tommy:  well, I think I'll have to ping you back unless you don't mind waiting longer.
Melissa:  Ok, let us know if there is anything else we can assist with.
Melissa:  I can also get you a phone number if you'd prefer to call/
Tommy:  wait
Tommy:  can you just give us a cert for 2 years?
Tommy:  instead of doing the anticipation thing?
Melissa:  It is a cert for 2 years. If you do not renew it will not be valid any longer.
Melissa:  You could try to reissue the certificate, but that would require a new CSR and installation.
Tommy:  this is a security concern of ours...can you change the expiration date to 2014?
Tommy:  I can definitely regenerate a CSR, no problem, but we want the expiration date to show 2014
Melissa:  I can transfer you to customer service but I do not believe that is an option unless you reissue. One moment.
Tommy:  k
Tommy:  k
Melissa has left the session.
Please wait while we find an agent from the VRSN Customer Support US department to assist you.
All agents are currently busy. Please stand by.
You have been connected to Erika F.
Erika F:  Hello. How may I assist you?
Tommy:  Hi, we just renewed pfd.phonefactor.net today. It is a 2 year cert, but the expiration date shows 2018. We would like to know if we can have that changed. It is a security concern of ours.
Erika F:  Unfortunately, we can not change the validity
Tommy:  If someone gets ahold of our cert, they have a valid cert for 6 years
Tommy:  We like the convenience of this concept, but not the security aspect, especially coming from Verisign/Symantec.
Erika F:  The certificate is valid for only 2 years. If you choose not to continue with the order when your 2 years is up, you would just pay for another term. You can continue renewing this way until 2018 when a new CSR will be required.
Tommy:  We don't want that.
Tommy:  We want a cert that only has 2 years.
Tommy:  To be clear: We want a cert that expires in 2 years :)
Erika F:  I understand, however I
Erika F:  *I'm not sure that the certificate will show only 2 years.
Erika F:  I am going to check with our technical support team right now.
Tommy:  thanks
Erika F:  Your welcome
Erika F:  I'm sorry I will go ahead and transfer you to our Sales team.
Erika F:  They would be the ones who can help with the validity.
Erika F:  One moment please while I transfer you to them. Please note they will be able to view the transcript.
Tommy:  ok
Erika F has left the session.
Please wait while we find an agent from the VRSN Sales United States (US) Channels SSL department to assist you.
You have been connected to Julian .
Julian :  Hello Tommy, please hold a moment while I review the chat history.
Tommy:  ok
Input Area
Enter chat text here, press enter to send
Images
Logo
Agent Image
Julian :  Thanks for holding Tommy. Unfortunately you were transferred to the incorrect Sales Team, let me get you over the Direct Sales Team for assistance with this, one moment please
Tommy:  :) ok
Julian :  It seems they are not available at the moment. Let me get your Account Manager to give you a call instead. Can Shane [REDACTED] reach you on [REDACTED]?
Tommy:  yes
Julian :  Thanks, he will be in contact with you as soon as possible

[Tommy relates that later he heard back from the rep who said that after investigating they cannot sell us a cert for 2 years, but would dig further.]

Comment 1

[Marsh Ray]

Has anyone considered how large this CRL is going to be in 6 years?

I suspect a great many websites do not persist for 6 years. In 2 years, the non-renewals will begin piling up, each one adding about 35 bytes to the CRL until its natural expiration date. In 6 years, it seems likely that a significant percentage of all certs issued over the preceding period will have an entry in this CRL.

Symantec/VeriSign says "As the leading supplier of trust services for the Internet, VeriSign has successfully issued SSL digital certificates to secure hundreds of thousands of Web sites". This is consistent with EFF's SSL Observatory report, which found approximately 200000 sites with VeriSign certificates.
http://www.verisign.com/static/001496.pdf
https://www.eff.org/files/DefconSSLiverse.pdf

This doesn't tell us directly the number of certificates issued, or the number that will need to be revoked over the coming years. But it seems likely that this CRL data will grow to many tens of MB at least, making CRL checking impractical for many clients.

Suggestion to Symantec/VeriSign: Start splitting up your CRL right away!

Comment 2

[Kathleen Wilson]

Marsh, Thank you for filing this bug to raise this concern, and for providing your thorough analysis. This practice of creating an SSL certificate with a validity period 4 years longer than what has been paid for is indeed disturbing.

As you pointed out, according to the CAB Forum Baseline Requirements, VeriSign will have to reduce the validity period of their new SSL certs to 5 years starting on July 1, 2012, and to 39 months starting on April 1, 2015. However, that still doesn't address the concern of having the validity period of the cert being much longer than what the customer requested/paid for.

It looks like VeriSign's assumption is that it will be easier for the customer to simply renew their agreement, than to have to generate a new certificate. I expect that VeriSign has statistics showing that this is the case, and is tracking the impact to their CRLs.

I have re-reviewed the VeriSign CPS, http://www.verisign.com/repository/CPS/, and it is not clear to me how VeriSign tracks re-authentication for certs such as this one, where you paid for 2 years, but the cert is valid for 6 years.

The CPS says: "Subscribers are required to undergo re-authentication at least every 3 years under Section 3.2.3."

Rick, How does VeriSign ensure that the appropriate re-authentication steps or revocation are taken after 2 years for certs like this one? Then (assuming proper re-authentication is done at two years), how does VeriSign ensure that the appropriate re-authentication steps or revocation is done at the following 3 year interval? (e.g. 5 years after the cert was issued)


> Suggestion to Symantec/VeriSign: Start splitting up your CRL right away!

Unfortunately, I don't think that NSS currently supports split CRLs.
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension

Brian, is that still the case?

Comment 3

[Kathleen Wilson]

Another questions for Rick...

The title of this bug seems to indicate that this SSL cert was issued after only DV, not OV, which would be against the policies documented in VeriSign's CPS. Would you please check on where the mis-match has occurred?

The title of this bug is "Secure against Symantec/Verisign DV certs being issued with excessive validity period (6 years!)"

The issuer of this cert is "VeriSign Class 3 Secure Server CA - G3"

My understanding, based on section 3.2.3 of the CPS, is that certs issued under Class 3 are OV. Also, according to section 1.4.1, SSL certs can only be issued under Class 3.

Comment 4

[Marsh Ray]

> Unfortunately, I don't think that NSS currently supports split CRLs.

Forgive me for trying to help improve the same process that I'm arguing against :-), but they might be able to put different CRL URLs in the certs they issue. I don't know if it would require separate intermediates.

I don't know how many clients these days download CRLs, but it seems a waste of bandwidth. Currently the CRL says:
        Last Update: Apr 24 09:00:33 2012 GMT
        Next Update: May  8 09:00:33 2012 GMT

There are two weeks between CRL updates. Perhaps this is due to bandwidth? An average lag of one week doesn't seem very good for a security control.

> The title of this bug seems to indicate that this SSL cert was issued after only DV, not OV

That was just my assumption, I was not involved in the 'V'.

I suspect there's a better title out there somewhere for this issue.

Comment 5

[Rick Andrews]

The title of this bug is incorrect. The cert that Marsh posted is an OV cert, not a DV cert. We don't issue DV certs under the VeriSign brand. This cert has a validated O field, O=PhoneFactor. Kathleen, can you please change the bug title?

Regardless of the validity period of the cert, we re-authenticate the customer whenever they come up for term renewal. So, for example, if a customer buys a one- or two-year cert and we issue them a six-year cert, we re-authenticate they every one or two years when their term is up.

Yes, we've thought about how big the CRL might get, and we monitor it. We won't do delta CRLs (called 'split' above) because there's very little support for them. Rather, we'll just re-key the intermediate CA and start a new CRL.

Comment 6

[Kathleen Wilson]

http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
"6. We require that all CAs whose certificates are distributed with our software products:
... verify that all of the information that is included in SSL certificates remains current and correct at time intervals of thirty-nine months or less;

According to VeriSign's CPS, they comply with this requirement, and we don't currently have policy about validity periods for OV SSL certs. VeriSign will be expected to follow the CAB Forum Baseline Requirements, according to the dates specified therein.

I believe that there are no further actions for Mozilla to take regarding this bug.

Comment 7

[Jacob Appelbaum]

(In reply to Kathleen Wilson from comment #6)
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
> "6. We require that all CAs whose certificates are distributed with our
> software products:
> ... verify that all of the information that is included in SSL certificates
> remains current and correct at time intervals of thirty-nine months or less;
> 
> According to VeriSign's CPS, they comply with this requirement, and we don't
> currently have policy about validity periods for OV SSL certs. VeriSign will
> be expected to follow the CAB Forum Baseline Requirements, according to the
> dates specified therein.
> 
> I believe that there are no further actions for Mozilla to take regarding
> this bug.

What happens if the CRL/OCSP servers aren't accessible by the client? It seems to fail open, no?

Comment 8

[Marsh Ray]

Thank you all for your time!