Problem: Multiple Web Browsers do not do not validate CN on certificates.

From: Simson L. Garfinkel (
Date: 05/07/03

  • Next message: Jouko Pynnonen: "Windows Media Player directory traversal vulnerability"
    Date: Wed, 7 May 2003 13:06:56 -0400 (EDT)

    Problem: Multiple Web Browsers do not do not validate CN on certificates.

    Effected Versons:
             Safari 1.0 Beta (v60)
             Safari 1.0 Beta 2 (v73)
             Konqueror Embedded (unknown version; common browser on Open Zaurus)
             [NOTE: Konquror 3.0.5 does not exhibit the problem.]

    Both versions of Safari were tested on MacOS 10.2.5 and 10.2.6.

    While doing work for an article on PKI, Jesse Burns and I discovered
    that Apple's Safari web browser does not validate the Common Name (CN)
    field on X.509 certificates that are downloaded to the client at the
    start of SSL/TLS sessions. This bug is particularly annoying because
    there is no way that we can find inside Safari to view the contents of
    a certificate; double-clicking on the "lock" icon does nothing.

    We are divided on whether or not this is a serious bug: Jesse feels
    that it is sufficient reason that people should stop using
    Safari until it is fixed. Simson feels that PKI has been deployed so poorly and is so
    meaningless that it really doesn't matter if Safari validates
    certificiates or not.

    Test vectors:

    Regarding Test Vector #1:

    Sandstorm's home page is web-hosted at Vineyard.NET, a small ISP on
    Martha's Vineyard. Because Vineyard.NET multi-homes its clients, the
    IP address is shared by both and
    Vineyard.NET's administrative server, However,
    because VIneyard.NET has enabled SSL only for its own internal use and
    not for its customers, points to,
    and the certficiate at is Vineyard.NET's.

    Regarding Test Vector #2:

    A "GET /" at retrieves a JavaScript
    document that executes the following:

     function time() {

    This does a second GET at a new domain; the certificate at actually has the common name of

    Internet Explorer 5.2.2 (5010.1) on MacOS did not exhibit the problem;
    it reported that the common name on the certificate did not match the
    entered DNS address with both of the two test vectors. The same
    behavior was seen with Internet Explorer 5.5 on Windows. The same
    behavior was seen with Opera 7.10 on Windows.

    Apple Computer has been been notified of this bug.

    Simson L. Garfinkel Jesse Burns
    MIT Laboratory for Computer Science

    Here is the full certificate:

    [simsong@r2 scan] 346 % openssl s_client -connect
    depth=0 /C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at (c)00/
    verify error:num=20:unable to get local issuer certificate
    verify return:1
    depth=0 /C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at (c)00/
    verify error:num=27:certificate not trusted
    verify return:1
    depth=0 /C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at (c)00/
    verify error:num=21:unable to verify the first certificate
    verify return:1

    Certificate chain
     0 s:/C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at (c)00/
       i:/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority
    Server certificate
    -----END CERTIFICATE-----
    subject=/C=US/ST=Massachusetts/L=Vineyard Haven/O=Vineyard.NET, Inc./OU=Terms of use at (c)00/
    issuer=/C=US/O=RSA Data Security, Inc./OU=Secure Server Certification Authority
    No client certificate CA names sent
    SSL handshake has read 1454 bytes and written 314 bytes
    New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
    Server public key is 1024 bit
        Protocol  : TLSv1
        Cipher    : EDH-RSA-DES-CBC3-SHA
        Master-Key: 4AD7B59E9D9D3E8953B17B293153A7D104C6CC023E7EC5877FFCAB5D9DD16695F8E867C47D5A656842A352E3EB568F8C
        Key-Arg   : None
        Start Time: 1052273380
        Timeout   : 300 (sec)
        Verify return code: 21 (unable to verify the first certificate)

  • Next message: Jouko Pynnonen: "Windows Media Player directory traversal vulnerability"

    Relevant Pages

    • Re: Unable to use stunnel with tin...
      ... Looks like you got an odd version of stunnel. ... was getting the certificate written correctly. ... Next verify you can connect to the server. ...
    • Re: SSL certificate check error ...
      ... These commands do not work without the CAfile specified on freebsd 8.x or 9.x either. ... I am seeing a problem with certificate checking on several stock FreeBSD ... When I try to run s_client as a test to, I see "Verify ... /etc/ssl/cert.pem is not being opened when I do not specify the option ...
    • RE: Verifying X509Certificate signature
      ... issue--with that sort of data I know what data to pass to Verify. ... As you said that you want some information about verifying X509 certificate ... Microsoft MSDN Online Support Lead ...
    • Re: Are ++ and -- operators really more efficient
      ... But you still need a way to verify that it's the right key. ... the signature contains a URL indicating ... where the certificate can be found. ... (This idea that public keys represent principals -- ...
    • Re: how can we restrict what certificate WSE will use?
      ... > X509SecurityTokenManager to verify the request is from a trusted client. ... > certificate to build a valid signature and encrypted data section. ...