Closed Bug 449394 Opened 16 years ago Closed 15 years ago

Enable WellsSecure Public Root Certificate Authority root for EV

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: hecker, Assigned: KaiE)

References

Details

Attachments

(6 files, 3 obsolete files)

a dump of the web server certificate (nerys.wellsfargo.com)
4.11 KB, text/plain
Details
dump of certificate with subject "Wells Fargo Default Responder"
2.29 KB, text/plain
Details
server cert nerys.wellsfargo.com (PEM format)
1.84 KB, text/plain
Details
new r (request)
69 bytes, application/octet-stream
Details
new R (response)
1.45 KB, application/octet-stream
Details
text dump of new R
6.28 KB, text/plain
Details 
Per bug 428390 I have approved the request from Wells Fargo to enable its
WellsSecure Public Root Certificate Authority root certificate for EV use. Please make the corresponding changes to PSM.

The relevant information is as follows:

Name: WellsSecure Public Root Certificate Authority

SHA-1 fingerprint:
E7 B4 F6 9D 61 EC 90 69 DB 7E 90 A7 40 1A 3C F4 7D 4F E8 EE

EV policy OID: 2.16.840.1.114171.500.9

Gordon, can you please do a final confirmation that this is the correct root and the correct EV policy OID?
Blocks: 428390
Depends on: 449393
Can you please provide an URL to a live Web Site that uses an EV certificate issued by this root?
Depends on: 449892
No feedback, no inclusion.

Gordon provided a test URL in bug 449393 comment 9:

https://nerys.wellsfargo.com/test.html

Unfortunately I ran into a problem with testing that URL.
I am not yet sure whether the issue is related to a problem in NSS, or whether it is caused by a bad configuration on the WellsSecure OCSP server.

As part of the EV validation, NSS attempts to use OCSP to obtain the status of the server certificate. That operation fails.

Gordon, based on my quick tests, it appears to me that your OCSP server is misconfigured.

NSS is unable to verify the certificate that signs the OCSP response, because NSS is unable to find the issuer certificate for the signing cert.

Gordon, could you please verify that your OCSP server does send out all required intermediate certificates when sending out OCSP responses?

we are sending an OCSP request for:

 ## SUBJECT:  CN=nerys.wellsfargo.com,OU=CAST PKI,O=Wells Fargo and Company,serialNumber=3511,OID.2.5.4.9=1300 W. Alameda Dr.,L=Tempe,ST=AZ,postalCode=85282,C=US,OID.1.3.6.1.4.1.311.60.2.1.3=US
 ## VALIDITY:  Fr Apr 25 02:23:18 2008 to Sa Apr 25 02:23:15 2009
 ## ISSUER:  CN=Wells Fargo Public Primary Certificate Authority,OU=Wells Fargo Certificate Authorities,O=Wells Fargo,C=US
 ## SERIAL NUMBER: 03:39
 ## requested validity time: Mo Aug 18 22:44:55 2008

we get a response.

there are not certs in the response

we attempt to find the signer certificate (that signed the response)

(gdb) print encodedName
$3 = {type = 3031855128,
  data = 0xb0c77241 "0|1\v0\t\006\003U\004\006\023\002US1\0200\016\006\003U\004\b\023\aArizona1\0160\f\006\003U\004\a\023\005Tempe1\0240\022\006\003U\004\n\023\vWells Fargo1\r0\v\006\003U\004\v\023\004CAST1&0$\006\003U\004\003\023\035Wells Fargo Default Responder\030\01720080818224456Z0R0P0;0\t\006\005+\016\003\002\032\005", len = 126}

  signerCert = CERT_FindCertByName(handle, &encodedName);

this fails, nothing found

and without the signer cert, we can't validate the signature
The OCSP request was sent to http://validator.wellsfargo.com/
and we got a response with http code 200 (good).

I'm trying to find that responder cert somewhere, so I could import it, and try again. If that succeeded, it would confirm the problem is the missing cert.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 825 (0x339)
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=Wells Fargo Public Primary Certificate Authority,OU=Wells
             Fargo Certificate Authorities,O=Wells Fargo,C=US"
        Validity:
            Not Before: Fri Apr 25 02:23:18 2008
            Not After : Sat Apr 25 02:23:15 2009
        Subject: "CN=nerys.wellsfargo.com,OU=CAST PKI,O=Wells Fargo and Compa
            ny,serialNumber=3511,OID.2.5.4.9=1300 W. Alameda Dr.,L=Tempe,ST=A
            Z,postalCode=85282,C=US,OID.1.3.6.1.4.1.311.60.2.1.3=US"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    a1:a5:cb:91:56:26:2c:d7:45:75:e9:02:43:47:64:00:
                    fc:76:ec:21:ac:cc:6b:04:00:6c:07:f7:ce:c7:3d:41:
                    a1:37:64:f6:7a:7b:4b:07:55:98:f4:51:56:c2:24:d9:
                    7f:75:79:96:fa:4c:b3:56:13:16:68:8f:7a:2b:b5:31:
                    0c:29:f9:7b:aa:14:ff:c6:57:9e:7c:88:7a:e2:fd:3e:
                    8f:ae:07:03:44:84:71:44:cd:af:89:d7:36:38:32:39:
                    69:e3:01:8a:c2:6e:77:b9:27:5a:05:fa:64:0d:0a:a6:
                    ff:01:ed:51:a2:53:48:f3:07:8f:6d:d9:c7:7e:5f:f5
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name: Certificate Basic Constraints
            Critical: True
            Data: Is not a CA.

            Name: Certificate Subject Alt Name
            DNS name: "nerys.wellsfargo.com"

            Name: Authority Information Access
            Method: PKIX Online Certificate Status Protocol
            Location: 
                URI: "http://validator.wellsfargo.com/"
            Method: PKIX CA issuers access method
            Location: 
                URI: "http://crl.pki.wellsfargo.com/wf_ev_00.crt"

            Name: Certificate Policies
            Data: 
                Policy Name: OID.2.16.840.1.114171.500.0.0
                    Policy Qualifier Name: PKIX CPS Pointer Qualifier
                    Policy Qualifier Data: "http://www.wellsfargo.com/cps/"
                Policy Name: OID.2.16.840.1.114171.500.9
                    Policy Qualifier Name: PKIX CPS Pointer Qualifier
                    Policy Qualifier Data: "http://www.wellsfargo.com/cps/"

            Name: Certificate Key Usage
            Critical: True
            Usages: Digital Signature
                    Key Encipherment

            Name: Extended Key Usage
                TLS Web Server Authentication Certificate

            Name: Certificate Authority Key Identifier
            Key ID:
                d1:83:86:3a:6c:43:0a:87:0c:db:7f:9c:a7:76:a9:24:
                4f:cf:16:9a

            Name: CRL Distribution Points
            URI: "http://crl.pki.wellsfargo.com/ev.crl"

            Name: Certificate Subject Key ID
            Data:
                0e:e4:65:e9:61:6e:ed:d7:6b:3c:82:52:db:9b:15:f0:
                64:79:04:24

    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Signature:
        12:3a:48:d5:84:18:98:d1:fd:92:10:f1:87:3a:6c:96:
        3f:c9:52:ff:45:db:7d:cb:d2:2a:c6:df:d1:2f:13:17:
        5f:b4:6a:ec:29:21:8f:5c:4d:46:5c:c0:e2:4d:0d:de:
        4b:60:99:6e:2c:57:50:d3:d5:c9:c9:5b:78:d8:53:55:
        5c:91:54:4e:91:c9:f7:98:5a:98:b6:bd:ff:4c:32:20:
        62:15:44:f9:e1:4e:21:0e:8f:af:ff:08:d2:0a:36:84:
        a7:d6:ee:2a:73:9a:00:90:3d:12:35:a9:6c:ac:33:4a:
        9f:e0:96:39:0b:50:df:d8:a8:87:ad:70:90:f0:04:49:
        2d:29:23:1b:46:19:87:58:86:95:ed:be:3a:d0:98:98:
        f6:34:49:ff:4b:dd:e6:b5:03:97:5b:c3:19:da:76:8e:
        7f:90:30:b8:de:29:5e:2a:82:d2:08:ee:ce:c6:f9:3d:
        31:47:0e:68:22:2e:e1:5e:67:82:2a:12:e0:a1:04:a4:
        5a:18:57:1c:ad:71:5d:10:48:1a:b5:7e:1e:19:6e:6f:
        19:66:fe:b8:71:05:47:b8:dc:e5:61:1f:63:38:25:a9:
        97:a8:84:f1:79:c4:fa:02:14:35:dc:a7:13:6c:fd:94:
        35:38:ef:ce:6a:2d:6f:5a:ea:5c:40:99:7e:89:53:31
    Fingerprint (MD5):
        FD:75:1E:76:B0:2F:44:16:2B:91:D2:EB:C2:16:2A:15
    Fingerprint (SHA1):
        47:B4:6B:C2:AB:EE:5E:D4:1A:EA:F1:B0:67:A5:FB:D7:23:52:EF:56


$ ./ocspclnt -r ws -d ~/.mozilla/firefox/pdtq476d.trunktest/ > r


$ ./ocspclnt -p -d ~/.mozilla/firefox/pdtq476d.trunktest/  < r
TBS Request:
    Version: DEFAULT
    No Requestor Name.
    Request 0:
        Cert ID:
            Hash Algorithm: SHA-1
            Issuer Name Hash:
                73:05:93:df:0a:6d:fd:d6:87:4e:e3:d6:14:56:0c:5c:
                59:38:7a:c7
            Issuer Key Hash:
                d1:83:86:3a:6c:43:0a:87:0c:db:7f:9c:a7:76:a9:24:
                4f:cf:16:9a
            Serial Number: 825 (0x339)
        No Single Request Extensions
    No Request Extensions
No Signature


$ ./ocspclnt -R ws -d ~/.mozilla/firefox/pdtq476d.trunktest/ > R


$ ./ocspclnt -P -d ~/.mozilla/firefox/pdtq476d.trunktest/  < R
Response Status: successful (Response has valid confirmations)
Response Bytes:
    Response Type: OCSP Basic Response
    Basic OCSP Response:
        Response Data:
            Version: DEFAULT
            Responder ID (byName):
                Name: "CN=Wells Fargo Default Responder,OU=CAST,O=Wells Fargo
                    ,L=Tempe,ST=Arizona,C=US"
            Produced At: Mon Aug 18 23:09:00 2008
            Response 0:
                Cert ID:
                    Hash Algorithm: SHA-1
                    Issuer Name Hash:
                        73:05:93:df:0a:6d:fd:d6:87:4e:e3:d6:14:56:0c:5c:
                        59:38:7a:c7
                    Issuer Key Hash:
                        d1:83:86:3a:6c:43:0a:87:0c:db:7f:9c:a7:76:a9:24:
                        4f:cf:16:9a
                    Serial Number: 825 (0x339)
                Status: Cert is unknown to responder.
                This Update: Mon Aug 18 23:09:00 2008
                No Next Update
                No Single Response Extensions
            No Response Extensions
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Signature:
            19:6d:83:39:dc:88:b3:24:33:31:28:89:79:13:0b:37:
            8d:77:04:7e:41:4d:f4:04:d8:f6:c8:3a:41:4c:d9:fd:
            f0:75:40:4e:92:2f:f1:d0:0b:eb:93:a0:be:c3:88:24:
            6a:4e:98:d8:91:de:82:f7:60:c4:b0:b5:35:27:66:aa:
            71:12:a1:5e:30:cd:79:2a:19:60:56:b6:7e:dc:71:af:
            83:25:0d:fb:8f:54:31:56:4e:f0:69:be:c2:85:a6:75:
            06:31:a0:d7:bd:eb:17:f3:7b:63:71:2b:12:54:78:49:
            e0:64:b6:23:49:ac:2f:5b:65:5e:74:ad:cf:98:55:f9
        No Certificates.
    Signature verification failed: security library: bad database.

Kai, please attach to this bug the file named 'R' from the experiment 
recorded in comment 7. Thanks.

    
    

    
  

      
      
      
      

        Attached file
          
        the file r (the binary request) (obsolete)
        — 
      

    


  

    
    

    
  


  
I've been given this certificate by email.

    
    

    
  
This looks very wrong to me.

- the certificate that signs the OCSP responses is missing,
  the OCSP server fails to send it out

- the certificate that signs the OCSP responses is a self signed cert,
  but it ought to be a cert that chains up to a CA cert.
  In fact, according to my understanding, it must chain up to the very
  same CA root cert that issued the cert we have requested to validate.

- for testing purposes, I assigned explicit trust to the response signer cert

- after I assigned the trust, I repeated the OCSP validation attempt

- now I get a different error message:
    The OCSP server has no status for the certificate.
    (Error code: sec_error_ocsp_unknown_cert)


In other words, your OCSP server (the one listed in your server cert) has no clue whether the requested cert is valid or not. And the response that says so ("have no clue") can not be validated by the client.

I believe this proofs the theory that EV can not work, because of a misconfigured OCSP infrastructure.

I propose to delay enabling EV until you have shown that your OCSP setup works.


    
    

    
  
In order to help you with testing your OCSP infrastructure, here is some advice:

Get the latest nightly experimental Firefox 3 build from here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0/

It should already contain your root, but not enabled for EV.

Go to advanced preferences, encryption, validation, and check the checkbox that says "When an OCSP server connection fails, treat the certificate as invalid".

Then connect to your own test site at 
https://nerys.wellsfargo.com/test.html

Please report back when you have reconfigured your infrastructure and Firefox can successfully connect with the above option set,
or,
when you have reason to believe that Firefox is behaving incorrectly.


    
    

    
  
See RFC 2560 section 4.2.2.2 for the requirements on an OCSP response signer's
certificate.  In short: the response signer's cert must be either the CA cert
that issued the cert being checked, or a delegated responder cert issued by
that same CA.  (I'm ignoring the "local configuration" case.)

If the response is signed by a delegated responder, and not by the CA itself 
(that is, if the response signature is verified using the public key from a 
delegated responder's certificate, and not using the public key from the CA's 
certificate) then the response signer's certificate is not optional.  The 
response must include it (except for the "local configuration" case, which 
I'm ignoring).



    
  
No longer depends on: 449892

    
  
Depends on: ev303

    
    

    
  
Nelson, Kai,  Thank you for your comments.  I am looking into our configuration and will post what I find.

    
    

    
  
Removing link to bug 451305, as this root is not ready for inclusion in FF 3.0.4
No longer depends on: ev303

    
    

    
  
We are still interested in EV Inclusion and we are working with our vendor to resolve any OCSP issues.

    
    

    
  
(In reply to comment #18)
> We are still interested in EV Inclusion and we are working with our vendor to
> resolve any OCSP issues.

Please let us know in this bug once you're ready, and we can resume testing and re-attempt inclusion. Thanks.

    
    

    
  
Kai,

Sorry for the delay in resolving this, we believe that we have resolved the issue we were experiencing with our OCSP responder and are ready to resume testing at this time.  You can still use our test site: https://nerys.wellsfargo.com/test.html for testing purposes.  We look forward to your feedback.

    
    

    
  
I attempted again to grant EV to your root.
It fails again, now with a different error.

    
    

    
  


  

        Attachment #334432 -
        Attachment is obsolete: true

        Attachment #334434 -
        Attachment is obsolete: true

    
    

    
  
I used 
certutil -A -n ws -d ~/.mozilla/firefox/pdtq476d.trunktest/ -i /tmp/nerys.wellsfargo.com -a -t ,,

to import the cert into a NSS database.

    
    

    
  

      
      
      
      

        Attached file
          
        new r (request)
        — 
      

    


  
$ ./ocspclnt -r ws -d ~/.mozilla/firefox/pdtq476d.trunktest/ > r


$ ./ocspclnt -p -d ~/.mozilla/firefox/pdtq476d.trunktest/  < r
TBS Request:
    Version: DEFAULT
    No Requestor Name.
    Request 0:
        Cert ID:
            Hash Algorithm: SHA-1
            Issuer Name Hash:
                73:05:93:df:0a:6d:fd:d6:87:4e:e3:d6:14:56:0c:5c:
                59:38:7a:c7
            Issuer Key Hash:
                26:61:85:72:eb:b2:96:ae:d3:f4:15:5f:04:31:b5:89:
                81:cb:40:d9
            Serial Number: 1206 (0x4b6)
        No Single Request Extensions
    No Request Extensions
No Signature

    
    

    
  

      
      
      
      

        Attached file
          
        new R (response)
        — 
      

    


  
$ ./ocspclnt -R ws -d ~/.mozilla/firefox/pdtq476d.trunktest/ > R

    
    

    
  

      
      
      
      

        Attached file
          
        text dump of new R
        — 
      

    


  
The dump finishes with:

Signature verification failed: Invalid OCSP signing certificate in OCSP response.

    
    

    
  
I don't know whether this result means the wellssecure ocsp responder is still incorrect, or whether this is a bug in NSS.

I propose Alexei/Nelson have a look at the files I've attached.

If they conclude that NSS behaves correctly, then the WellsSecure engineers should use the NSS tools and repeat the tests illustrated in this bug, and enhance their server environment until the tests work, or until they are able to report a bug in NSS.

    
  

        Attachment #366840 -
        Attachment description: test dump of new R → text dump of new R

    
    

    
  
I'm going to produce a Firefox test build that includes the EV blessing for the WellsSecure root.

  {
    // CN=WellsSecure Public Root Certificate Authority,OU=Wells Fargo Bank NA,O=Wells Fargo WellsSecure,C=US
    "2.16.840.1.114171.500.9",
    "WellsSecure EV OID",
    SEC_OID_UNKNOWN,
    "E7:B4:F6:9D:61:EC:90:69:DB:7E:90:A7:40:1A:3C:F4:7D:4F:E8:EE",
    "MIGFMQswCQYDVQQGEwJVUzEgMB4GA1UECgwXV2VsbHMgRmFyZ28gV2VsbHNTZWN1"
    "cmUxHDAaBgNVBAsME1dlbGxzIEZhcmdvIEJhbmsgTkExNjA0BgNVBAMMLVdlbGxz"
    "U2VjdXJlIFB1YmxpYyBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eQ==",
    "AQ==",
    nsnull
  },

I'll let you know when this build is done.
Hopefully it will allow us to avoid further experiments until you are able to report a successful test with your test servers and that test build.

    
    

    
  
Ok, looks like this is a bug in NSS.

For testing purposes, when calling into the NSS libpkix verification function, I disabled the CRL check, and only requested OCSP. This gave me valid EV.

I recently saw a report in a different bug that NSS reports a failure for certificates that list both CRLDP and OCSP AIA, and the server cert is such a cert listing both.

    
    

    
  
(In reply to comment #29)
> I recently saw a report in a different bug that NSS reports a failure for
> certificates that list both CRLDP and OCSP AIA, 

I'm not aware of any such bug.

    
    

    
  
(In reply to comment #30)
> (In reply to comment #29)
> > I recently saw a report in a different bug that NSS reports a failure for
> > certificates that list both CRLDP and OCSP AIA, 
> 
> I'm not aware of any such bug.

I was referring to comments in bug 477244 comment 67.
But that comment has not been verified.
My reference was a guess.

Meanwhile I have done more testing on this WellsSecure issue.
I've now used the most recent snapshot of NSS to avoid confusion.

I'll explain the new findings in the next comments.

    
    

    
  
EV verification fails as soon as we attempt to use OCSP to validate the intermediate cert.

Here is a dump of the response received when asking the OCSP responder for information about the intermediate cert "WellsFargoPublicPrimaryCertificateAuthority".


Response Status: successful (Response has valid confirmations)
Response Bytes:
    Response Type: OCSP Basic Response
    Basic OCSP Response:
        Response Data:
            Version: DEFAULT
            Responder ID (byName):
                Name: "CN=Wells Fargo Default Responder,OU=CAST,O=Wells Fargo
                    ,L=Tempe,ST=Arizona,C=US"
            Produced At: Wed Mar 11 22:14:59 2009
            Response 0:
                Cert ID:
                    Hash Algorithm: SHA-1
                    Issuer Name Hash:
                        6e:bf:42:ee:b4:d0:d0:fa:0c:62:71:e9:73:80:bd:c3:
                        e7:7b:40:ab
                    Issuer Key Hash:
                        26:95:19:10:d9:e8:a1:97:91:ff:dc:19:d9:b5:04:3e:
                        d2:73:0a:6a
                    Serial Number: 413 (0x19d)
                Status: Cert is good.
                This Update: Thu Feb 26 17:33:24 2009
                Next Update: Thu Mar 12 04:14:59 2009
                No Single Response Extensions
            No Response Extensions
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Signature:
            1b:38:c2:cb:91:d9:59:fa:a1:ac:4c:95:36:05:f9:92:
            32:59:fc:6d:ec:1e:c0:9c:a9:58:86:b8:65:c8:78:93:
            88:10:56:7a:df:00:f1:b7:3c:fd:2a:08:93:e9:24:7c:
            78:ba:54:ac:9d:77:39:d0:0c:5b:54:40:20:8e:5a:10:
            ab:c6:c1:90:6e:f8:23:c3:29:be:a8:99:0a:a8:26:54:
            53:7d:27:cb:c6:c9:65:b8:ba:ec:0a:86:f8:4a:ec:b2:
            71:4c:da:a3:7f:4d:9f:36:16:43:49:e5:ed:88:cc:ef:
            de:1a:b1:ee:2e:c9:2d:02:ef:64:f3:c1:b9:e8:59:90
        No Certificates.
    Signature verification failed: Unrecognized Object Identifier.

    
    

    
  
Kai, when the ocspclnt program is used like pp, to "pretty print" a 
request or response, it may misdiagnose the request or response because
it lacks the information necessary to do correct diagnosis.  For example,
it is not possible to tell if the response has a valid signer or not by 
examining the response alone.  It is necessary to also have the original
cert chain for which the request was sent, as well as any "local" 
configuration of the "default" (user delegated) responder.

Only the option that takes the name of a cert whose chain is in the 
cert DB and checks that can produce diagnostics that are consistent with 
the behavior seen in FF, IINM.

    
    

    
  
Nelson, in my tests I never use a user delegated/configured responder. I think that's a pretty rare configuration... I always use the "default behavior" of the tool, which I believe is, to use the responders listed in the certs.

In my test that led to the output in comment 32, I used a cert database that has the built-in roots module added to it using modutil.

When I used the pretty-print option from ocspclnt for the intermediate cert, my cert database contained that intermediate. And that intermediate is directly issued by one of the built-in roots. I believe the ocspclnt tool had all necessary certificates available when it produced the output in comment 33.

    
    

    
  
So, I would like to give the ball back to WellsSecure representatives.

FYI, in regular SSL we use revocation testing on the leaf cert, only.
However, for EV, we try to test the intermediate certs on the chain for revocation info, too.
This is where we get a failure.

@NSS team: I can reproduce this failure using vfychain.

vfychain -d . -pp -a -u 1 -v -o OID.2.16.840.1.114171.500.9   -g leaf -h requireFreshInfo -m ocsp -s requireInfo -m crl   -g chain -m ocsp        nerys.wellsfargo.com

Chain is bad, -8180 = Peer's Certificate has been revoked.
PROBLEM WITH THE CERT CHAIN:
CERT 2. Builtin Object Token:WellsSecure Public Root Certificate Authority [Certificate Authority]:
  ERROR -8180: Peer's Certificate has been revoked.


vfychain -d . -pp -a -u 1 -v -o OID.2.16.840.1.114171.500.9   -g leaf -h requireFreshInfo -m ocsp -s requireInfo -m crl   -g chain -m ocsp        WellsFargoPublicPrimaryCertificateAuthority

Chain is bad, -8180 = Peer's Certificate has been revoked.
PROBLEM WITH THE CERT CHAIN:
CERT 1. Builtin Object Token:WellsSecure Public Root Certificate Authority [Certificate Authority]:
  ERROR -8180: Peer's Certificate has been revoked.


cert db contains roots module, nerys' server cert, and the intermediate cert, the same two certs I specified on the command line.

I get the same behavior, specifying either a filename or a nickname for the certs already in the db.

    
    

    
  
the issuing CA was re-issued in order to support an issue re: cross certification with a legacy root. Please ensure that you are testing with the following intermediate certificate:

Serial Number ‎01 9d
Monday, September 15, 2008 2:56:03 PM
Saturday, September 15, 2018 2:56:03 PM

Also obtainable here:

http://crl.pki.wellsfargo.com/wf_ev_00.crt

-----BEGIN CERTIFICATE-----
MIIFHDCCBASgAwIBAgICAZ0wDQYJKoZIhvcNAQEFBQAwgYUxCzAJBgNVBAYTAlVT
MSAwHgYDVQQKDBdXZWxscyBGYXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2Vs
bHMgRmFyZ28gQmFuayBOQTE2MDQGA1UEAwwtV2VsbHNTZWN1cmUgUHVibGljIFJv
b3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA4MDkxNTIxNTYwM1oXDTE4MDkx
NTIxNTYwM1owgYwxCzAJBgNVBAYTAlVTMRQwEgYDVQQKEwtXZWxscyBGYXJnbzEs
MCoGA1UECxMjV2VsbHMgRmFyZ28gQ2VydGlmaWNhdGUgQXV0aG9yaXRpZXMxOTA3
BgNVBAMTMFdlbGxzIEZhcmdvIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRlIEF1
dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN/RQjD9MC8I
k/SmQ4omM9Eck0dlOiACtIK/h+uSfdbEGFMZIHJ12wPNYsa+Bpj11KRZSthH6sRJ
eRKivEI/cHd/Ya6+G4Ovrodvjp4qA4C+nBgnYSbitWlQDhWswMBcLQdUOh58qV7y
jiKzN+RVZBdO0Dug2ZEVovFAUg+dtvPczFo8XXQgPKAH7SlDvisW2rT8h81pvWmB
5iPHoK6Zsk3PEUzLv/2HZiVtMQFCpZ3IbS/eIa30vm3HvhMlNNh1ww1sGk6TBVVQ
/sTU4fkoWWKGJ+Pe64FnG9uOVulcQcKirWubibN0tvPPEqcTvXpLiyMagmfTZa65
Szupfm2SYkECAwEAAaOCAYswggGHMA8GA1UdEwEB/wQFMAMBAf8wcgYIKwYBBQUH
AQEEZjBkMCwGCCsGAQUFBzABhiBodHRwOi8vdmFsaWRhdG9yLndlbGxzZmFyZ28u
Y29tLzA0BggrBgEFBQcwAoYoaHR0cDovL2NybC5wa2kud2VsbHNmYXJnby5jb20v
d3NwcmNhLmNydDCBuwYDVR0gBIGzMIGwMDkGC2CGSAGG+3uDdAAAMCowKAYIKwYB
BQUHAgEWHGh0dHA6Ly93d3cud2VsbHNmYXJnby5jb20vY3AwOQYLYIZIAYb7e4N0
AAEwKjAoBggrBgEFBQcCARYcaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNvbS9jcDA4
BgpghkgBhvt7g3QJMCowKAYIKwYBBQUHAgEWHGh0dHA6Ly93d3cud2VsbHNmYXJn
by5jb20vY3AwDgYDVR0PAQH/BAQDAgHGMB8GA1UdIwQYMBaAFCaVGRDZ6KGXkf/c
Gdm1BD7ScwpqMBEGA1UdDgQKBAhEMbWJgctA2TANBgkqhkiG9w0BAQUFAAOCAQEA
dYyusLRckUZlHyaOL1akdq9bAGpc1qr2+ZkCcjzYMuRY3/vMpPZD/++5iI688nDL
ovg1ijMD8URQNdm+Ku9YW7hFcL40aO0KXLWn+wka/lxv5KF34UQwGsiKfXcZ/Dbz
GQ8OtgXieACXg8QmQJlZKu7fEAvX12nwhX02GKrcsgBLcdiVLauzeY6O61pfPL6Z
P+iwrVP2MaGKm1cxZG1Cmw7ZHPSDdwAWzYMt5hcg7eexXkm5MC6/EGXGfIxHe/W9
++NCGL/X4/MWkvoaPh+7/ecn71yC4TfeM+REwBYjO8CuCepgxW/b/8FKU62fxB1s
nI7viYaF/ru+3cndWupGzg==
-----END CERTIFICATE-----

Gordon Young
Wells Fargo
PKI Ops Team

    
    

    
  
As well please use this certificate to validate signatures on the OCSP responses re: EV_SSL

-----BEGIN CERTIFICATE-----
MIIEJTCCAw2gAwIBAgIBHzANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCVVMx
FDASBgNVBAoTC1dlbGxzIEZhcmdvMSwwKgYDVQQLEyNXZWxscyBGYXJnbyBDZXJ0
aWZpY2F0ZSBBdXRob3JpdGllczE5MDcGA1UEAxMwV2VsbHMgRmFyZ28gUHVibGlj
IFByaW1hcnkgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA4MDkyOTIzMTYwMVoX
DTExMDkyOTIzMTQzM1owaTEUMBIGA1UECgwLV2VsbHMgRmFyZ28xLDAqBgNVBAsM
I1dlbGxzIEZhcmdvIENlcnRpZmljYXRlIEF1dGhvcml0aWVzMSMwIQYDVQQDDBpX
ZWxscyBGYXJnbyBFVjAwIFJlc3BvbmRlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAv/TLtnFmM12hEBxrw79asGOx/Bz9/AzAKKPrTv/SAD/OzNzE3nIuhxPd
r55VHVVyQISCbxRUyohTmHOeGuTi9lP1bPuHxGu7DYyjjg4szWmuE+VgUp5I+r5p
O2I4lwjGRsfVnlNyUNAchMGY5BckiZfQrayxOt5aHt3c2scGKKUCAwEAAaOCATYw
ggEyMAkGA1UdEwQCMAAwgYMGA1UdIAR8MHowOwYLYIZIAYb7e4N0AAAwLDAqBggr
BgEFBQcCARYeaHR0cDovL3d3dy53ZWxsc2ZhcmdvLmNvbS9jcHMvMDsGC2CGSAGG
+3uDdAABMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cud2VsbHNmYXJnby5jb20v
Y3BzLzAPBgkrBgEFBQcwAQUEAgUAMA4GA1UdDwEB/wQEAwIGwDATBgNVHSUEDDAK
BggrBgEFBQcDCTATBgNVHSMEDDAKgAhEMbWJgctA2TA1BgNVHR8ELjAsMCqgKKAm
hiRodHRwOi8vY3JsLnBraS53ZWxsc2ZhcmdvLmNvbS9ldi5jcmwwHQYDVR0OBBYE
FEfEF6CMIUE3WM57g+Yj2ZnJQ7YzMA0GCSqGSIb3DQEBBQUAA4IBAQAhdCa5JIhL
hj2Wp5UD5o58OVZxqG/qdVtumOyhrIksPktOCV7LQ7g6+Iq85fuKQ2YfjiS12S0b
HuOlI/BIu41sJ4r+y7GSX1jJgjah04eEDAMavtu79Qb+POsySy2/LDe023xZRfQi
4HIme54fAe6ueP1s6F3RKxzLJkWlRfshlBDb4R1KhwtCtr8ow82r8bj7QEEHAME+
PBiYAIzbmIS2AP3uL5NhF+pA6Rj2yfSpE46K1rW0oyypsG4rUqovVr+66oSpMyNo
9/ZrGvMex9eEvfx0zSZxn5mnl2UOCTEfw/3GWpuG1FgvoYDWdoZ94JM9YUGKxkKx
EMtTz7/3D3wh
-----END CERTIFICATE-----

~Gordon

    
    

    
  
Kai, it would be very useful if the error code could differ in case for intermediate CAs. Is this possible to implement within a useful time frame?

    
    

    
  
(In reply to comment #37)
> As well please use this certificate to validate signatures on the OCSP
> responses re: EV_SSL

I don't quite understand.

Why am I required to manually import a certificate to validate OCSP repsonses?
Isn't everything that's required expected to be part of the OCSP response?

I have tried and imported the cert from comment 37 into my cert database, and I still get the same failure.

    
    

    
  
(In reply to comment #38)
> Kai, it would be very useful if the error code could differ in case for
> intermediate CAs. Is this possible to implement within a useful time frame?

You could file a separate enhancement request against NSS libraries. I can't say how likely this is to happen and when.

    
    

    
  
(In reply to comment #36)
> the issuing CA was re-issued in order to support an issue re: cross
> certification with a legacy root. Please ensure that you are testing with the
> following intermediate certificate:

I deleted the other intermediate, and imported your new intermediate from comment 36. No change, still fails.

    
    

    
  
Kai,

Again thank you for your work on this, much appreciated.

My appologies here. In reading the debug I see that NSS is indicating that the peer's (End Entity) certificate has been revoked, which it has, per my earlier comment regarding rebuilding the CA to support cross certification with a legacy root. The current certificate to test with would be the cert present on the server:
https://nerys.wellsfargo.com/test.html

which is given here:
‎serial# 04 b6
Thursday, January 22, 2009 4:59:23 PM
Saturday, January 22, 2011 4:59:23 PM

CN = nerys.wellsfargo.com
OU = PKI
O = Wells Fargo and Company
SERIALNUMBER = 02649647
STREET = 2600 S. Price
L = Chandler
S = AZ
PostalCode = 85286
C = US
1.3.6.1.4.1.311.60.2.1.2 = California
1.3.6.1.4.1.311.60.2.1.3 = US

-----BEGIN CERTIFICATE-----
MIIFLTCCBBWgAwIBAgICBLYwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAlVT
MRQwEgYDVQQKEwtXZWxscyBGYXJnbzEsMCoGA1UECxMjV2VsbHMgRmFyZ28gQ2Vy
dGlmaWNhdGUgQXV0aG9yaXRpZXMxOTA3BgNVBAMTMFdlbGxzIEZhcmdvIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wOTAxMjIyMzU5MjNa
Fw0xMTAxMjIyMzU5MjNaMIHpMRMwEQYLKwYBBAGCNzwCAQMTAlVTMRswGQYLKwYB
BAGCNzwCAQIMCkNhbGlmb3JuaWExCzAJBgNVBAYTAlVTMQ4wDAYDVQQRDAU4NTI4
NjELMAkGA1UECAwCQVoxETAPBgNVBAcMCENoYW5kbGVyMRYwFAYDVQQJDA0yNjAw
IFMuIFByaWNlMREwDwYDVQQFEwgwMjY0OTY0NzEgMB4GA1UECgwXV2VsbHMgRmFy
Z28gYW5kIENvbXBhbnkxDDAKBgNVBAsMA1BLSTEdMBsGA1UEAwwUbmVyeXMud2Vs
bHNmYXJnby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALrcOSkhC6+2
TZTpm+IbeKL1plNOMgiF+1tQUzzIn3G2JKZXooPGxqzavI/UXFEt2lTR+cjnnla4
B3NNnBkDjDiz8KoC7EfTil1NiSmJhOQGrNeR56pJKfEUDLkG+X+Yaya7uwo6F4LK
XIWhhHklQCbyCPvgDEq9K56GecXzFfe/AgMBAAGjggG8MIIBuDAMBgNVHRMBAf8E
AjAAMB8GA1UdEQQYMBaCFG5lcnlzLndlbGxzZmFyZ28uY29tMHQGCCsGAQUFBwEB
BGgwZjAsBggrBgEFBQcwAYYgaHR0cDovL3ZhbGlkYXRvci53ZWxsc2ZhcmdvLmNv
bS8wNgYIKwYBBQUHMAKGKmh0dHA6Ly9jcmwucGtpLndlbGxzZmFyZ28uY29tL3dm
X2V2XzAwLmNydDCBgAYDVR0gBHkwdzA6BgtghkgBhvt7g3QAADArMCkGCCsGAQUF
BwIBFh1odHRwOi8vd3d3LndlbGxzZmFyZ28uY29tL2NwLzA5BgpghkgBhvt7g3QJ
MCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cud2VsbHNmYXJnby5jb20vY3AvMA4G
A1UdDwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATATBgNVHSMEDDAKgAhE
MbWJgctA2TA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3JsLnBraS53ZWxsc2Zh
cmdvLmNvbS9ldi5jcmwwHQYDVR0OBBYEFP6QLgIIJzxZtuIZ87bRXkd4/LDzMA0G
CSqGSIb3DQEBBQUAA4IBAQBF9ddG/3hspkvECE/iIF2R+XhuosVePGI1tXBfShyj
dxO2Q/0LCDFVaC/Ukb8pA0p6YuTfTyy8Jn77/UlpBokadPDRSPsXed1iwSTk6LdJ
/a6IJYC02Vm/Ocu0RV0Lg0dz6iU4Ll/2pajJghdh30DueP916uStQbmzuEcX4Pbv
jdfQUf2ZhlJ/1UhPNbolt3IOo6QsBXUKxDPrRJLcYoHwXrMMAZCgGWZn6QCUAC0/
cCvxXIoCyZAQrD2Bp9HCYp5p8xiV9lgXfb/GMl10XD9SIuubeCtJ8IPEuWvZiITD
XQKP7G4YQsyX4/WjaV+ywq5dyNeTdWYP5rKiwXYDxiru
-----END CERTIFICATE-----

    
    

    
  
NSS might be buggy.

The cert DB in my firefox profile had two intermediates and one responder from WellsFargo imports in its database.

With that configuration, visiting your test site resulted in "EV failure".

I deleted the 3 certs for testing and tried again.

Now when I connect again to your test site (using experimental trunk), I get green EV.

    
    

    
  
While Kai is out, I have tried to reproduce his results.  
I am finding that the OCSP server rejects the OCSP request for the 
intermediate CA cert's status.  The http response reads:

HTTP/1.0 403 Forbidden..
Server: Tumbleweed Valicert VA 4.9..
Content-type: text/plain..
Content-length: 25..
Connection: Close..
..
Rejected :Error in format..
No longer depends on: 418644

    
    

    
  
WellsSecure: Maybe using the test build at https://build.mozilla.org/tryserver-builds/2009-03-11_10:52-kaie@kuix.de-kaie-evroots-0903/

can help you debug your OCSP environment?

We need to see a successful test before we can enable your root.

    
    

    
  
We are uploading an OCSP signing cert for our intermediate CA Thursday night.  We will then test it using the build Kai provided.  This new build from Kai should help us greatly in verifying that the functionality is where we need it to be to enable the green bar.

All of our previous testing was based on the fact that there is no error presented by Firefox 3 and we see the green bar when we view the test site with IE7.

We will post our results here.

    
    

    
  
We have finished testing with the Shiretoko browser and are pleased to report that we have seen a green bar with this test build.  Kai can you please verify this works and advise on how to proceed with the activation process.

    
    

    
  
Kai,

Have you had a chance to verify our test results with the Shiretoko Browser?  Please update this ticket with the current status.

Thank you

    
    

    
  

      
      
      
      

        Attached patch
          
          
        WellsSecure EV OID patch (obsolete)
        — 
          — Splinter Review
      

    


  
Contains also Secom Trust from previous patch. Recent EV enablement patches will be combined into one patch - this is one is for my reference.

    
  
Depends on: 493709

    
  

        Attachment #378289 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 378289 [details] [diff] [review]
WellsSecure EV OID patch

Obsoleted by attachment 378295 [details] [diff] [review]

    
    

    
  
Does this mean that our functionality has been verified and that we are being included?

    
    

    
  
I only created the patch for your EV OID upon request from Nelson and it appears to be working correctly. However final judgment should be only made after a current nightly or try-built was produced after applying the patch.

    
    

    
  
Thank you,  Will the results be posted here?

    
    

    
  
Most likely you'll be invited to review and confirm the expected result by yourself.

    
    

    
  
I believe this bug was fixed by the checkin for 
Bug 493709 -  Combined EV enablement 
so I am resolving this bug as fixed.  
Please reopen it if it is not fixed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: