Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

When visiting Gmail in Chrome, if I click on the lock icon in the address bar and go to the connection tab, I received a message 'The identity of this website has been verified by Google Internet Authority G2 but does not have public audit records.'

What exactly does it mean that the certificate does not have public audit records? Are their certain threats a site using a certificate without public audit records has that a site using a certificate with public audit records does not?

share|improve this question
11  
I see you had to take a screenshot to export the message. If you think it should be easier to copy the connection information out of Chrome, vote for code.google.com/p/chromium/issues/detail?id=254249 –  Colonel Panic Sep 5 '14 at 10:57
2  
Has anyone found an example with public audit records? –  Colonel Panic Sep 12 '14 at 16:19
2  
For an example with public audit records, see embed.ct.digicert.com . It's a purpose test site. Perhaps we'll see transparency proofs on real sites (most likely Google and Twitter) next year. –  Colonel Panic Oct 22 '14 at 17:26
    
Update February 2015: twitter.com is now "publicly auditable" in Chrome. You'll see a link "transparency information" to open a dialog "signed certificate timestamps viewer". –  Colonel Panic May 20 at 15:08

4 Answers 4

up vote 113 down vote accepted

Note: If you're here because your certificate suddenly isn't trusted by chrome, see the note about Chrome certificate trust at the bottom of this answer.

Comparison of auditable versus no audit record

This has to do with the concept of Certificate Transparency.

The Problem

Browsers currently trust certificates if four conditions are met: (a) the certificate is signed by a trusted CA, (b) the current time is within the valid period of the certificate and signing certs (between the notBefore and notAfter times), (c) neither the certificate nor any signing certificate has been revoked, and finally, (d) the certificate matches the domain name of the desired URL.

But these rules leave the door open to abuse. A trusted CA can still issue certificates to people who shouldn't have them. This includes compromised CAs (like DigiNotar) and also CAs like Trustwave who issued at least one intermediate signing certificate for use in performing man-in-the-middle interception of SSL traffic. A curated history of CA failures can be found at CAcert's History of Risks & Threat Events to CAs and PKI.

A key problem here is that CAs issue these certificates in secret. You won't know that Trustwave or DigiNotar has issued a fraudulent certificate until you actually see the certificate, in which case you're probably the perpetrator's target, not someone who can actually do any real auditing. In order prevent abuse or mistakes, we need CAs to make the history of certificates they sign public.

The Solution

The way we deal with this is to create a log of issued certificates. This can be maintained by the issuer or it can be maintained by someone else. But the important point is that (a) the log can't be edited, you can only append new entries, and (b) the time that a certificate is added to the log is verified through proper timestamping. Everything is, of course, cryptographically assured to prevent tampering, and the public can watch the contents of the log looking to see if a certificate is issued for a domain they know it shouldn't have.

If your browser then sees a certificate that should be in the log but isn't, or that is in the log but something doesn't match (e.g. the wrong timestamp, etc), then the browser can take appropriate action.

What you're looking at in Chrome, then, is an indication as to whether a publicly audible log exists for the certificate you're looking at. If it does, Chrome can also check to see whether the appropriate log entry has been made and when.

How widely is it used?

Google maintains a list of "known logs" on their site. As of this writing, there are logs maintained by Google, Digicert, Izenpe, and Certly, each of which can maintain the audit trail for any number of CAs.

The Chrome team has indicated that EV certificates issued after 1 Jan 2015 must all have a public audit trail to be considered EV. And after the experience gained dealing with EV certificate audit logs has been applied, they'll continue the rollout to all certificate issuers.

Note about Chrome certificate trust

If your cert suddenly stopped being recognized and your search for "public audit records" brought you here, then this is the bit you're looking for: Recently Chrome stopped trusting certificates that otherwise appear to be valid. You probably saw something that looks like this:

The identity of this website has been verified by RapidSSL CA but does not have public audit records. The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.  The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it.

While the bit about the public audit record is listed first, that's not actually the attribute that Chrome is alerting on. Instead, the important bit is that second section which says this: "The site is using outdated security settings that may prevent future versions of Chrome from being able to safely access it."

If you look a little further down, you should see something like this:

The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and DHE_RSA as the key exchange mechanism.

It's that SHA1 bit that matters. If that's there, then that's your problem. Basically Chrome is phasing out acceptance of the SHA1 hashing algorithm for key signatures. It's caught quite a few people by surprise, but your certificate authority who issued the cert is well aware of the issue and will most likely give you a replacement certificate for free. In fact, many CAs are actually giving away free certs to anyone who is affected, no matter where they got their original certificate from. Such is the nature of the CA business.

You can read more about Chrome's SHA1 changes here on the Google Security blog.

share|improve this answer
    
This is a great answer but leaves the question open as to why on earth Google, doesn't use a cert that is audible? Is this just not available at all yet and Google is putting the indicator in Chrome there to try to get CAs to change? –  Fraggle Jan 13 at 13:11
    
@Fraggle Google does something even better. They pins their certs using HSTS, and more impressively, ship their browser (Firefox too) with the correct HSTS entries preloaded. So firefox and chrome won't even ALLOW you to use a fraudulent google certificate, no matter who signed it. The same protection is extended to anyone else who asks. –  tylerl Jan 13 at 15:15
    
@tylerl, Nope. The protection only goes to privileged big boys like Google etc. It's not a solution that would scale. If you had a site my_site.com and you tell Google to add my_site.com to their preloaded STS list in Chrome, they would simply ignore you. And even if STS list is implemented, it still wouldn't stop the MITM attacks. –  Pacerier Jan 16 at 13:34
1  
@Pacerier it really is open to anyone. Here is where you add your site: hstspreload.appspot.com –  tylerl Jan 16 at 15:25
    
@Pacerier Sts doesn't stop mitm, but pinning does. And chrome supports pinning via your STS entry. –  tylerl Jan 16 at 15:27

This is a project by Google called Certificate Transparency that attempts to fix flaws with the SSL certificate system.

It essentially has three main goals. (Lifted from http://www.certificate-transparency.org/what-is-ct)

  • Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
  • Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued.
  • Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.

Source: http://www.certificate-transparency.org/certificate-transparency-in-chrome

share|improve this answer

As of January 1, 2015 all EV certificates are required to have public audit records (Signed Certificate Timestamps). The most common way of including these records is through Embedded SCTs. This method includes a new certificate extension/OID (1.3.6.1.4.1.11129.2.4.2) in the certificate file itself.

For OV and DV certificates, you can request that your CA add your certificates to its CT logs. I know that DigiCert will do this. Eventually, these certificate types will likely also be required to have CT enabled.

In order to have the SCTs embedded, you'll need to reissue any certificate you'd like to have the Public Audit Records after your CA has enabled them for your certs.

share|improve this answer

What exactly does it mean when Chrome reports a certificate 'does not have public audit records'?

I think Tyler did a great job of explaining the message and CT, so there's no need in rehashing it.

Based on @Colonel Panic's comment for a test site, here's what the end entity (server) certificate looks ike. Note: you must use TLS 1.0 (or above) and Server Name Indication to get the correct certificate. That's the -servername option below.

$ openssl s_client -connect embed.ct.digicert.com:443 -tls1 -servername embed.ct.digicert.com | \
    openssl x509 -text -noout
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify error:num=20:unable to get local issuer certificate
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:e0:aa:80:19:13:06:8a:28:73:f0:24:29:3e:e4:61
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
        Validity
            Not Before: Nov 13 00:00:00 2014 GMT
            Not After : Nov 18 12:00:00 2015 GMT
        Subject: C=US, ST=Utah, L=Lehi, O=DigiCert, Inc., CN=embed.ct.digicert.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9a:64:73:61:53:66:b8:aa:80:c7:cc:53:67:6a:
                    df:da:a9:b1:6a:c5:53:63:55:5f:14:4c:b3:27:d1:
                    3c:e4:0a:1a:e7:16:48:bc:15:46:7e:63:e8:27:3c:
                    c5:28:bd:79:cf:34:d5:9a:67:1e:0c:27:6e:ec:00:
                    5e:69:38:5b:a7:16:4f:b9:09:ec:fc:7e:f2:41:b7:
                    f9:54:f4:6c:c3:22:a6:f5:99:f4:be:9d:64:26:75:
                    9e:b2:b9:16:d7:f5:51:9f:53:ce:74:ca:d6:d6:7a:
                    4a:d4:4d:0e:4d:73:93:30:3c:b9:b8:1d:a0:d8:94:
                    8c:59:7e:82:a4:4c:82:fc:c3:73:7f:b1:56:28:4e:
                    b5:f7:73:53:ac:7b:30:a4:bc:b9:6c:c0:b6:67:0d:
                    19:5e:40:22:11:11:8c:6d:3a:87:47:08:e6:5c:7b:
                    17:7c:64:7a:a1:ff:8c:7c:37:b6:b7:91:2c:c2:90:
                    7e:cc:48:1f:57:1e:f9:db:d4:ac:cf:d9:2b:60:ff:
                    13:2d:88:c5:7e:d8:eb:ec:ed:85:d7:9e:f9:56:32:
                    ca:c1:6b:24:64:9f:63:ba:83:ee:a1:85:4a:e3:ad:
                    45:8c:92:95:3a:e0:80:91:9b:60:b5:75:88:86:4e:
                    0f:81:8c:b5:f4:77:fd:e5:f3:36:f6:33:d6:2b:a0:
                    c4:91
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:0F:80:61:1C:82:31:61:D5:2F:28:E7:8D:46:38:B4:2C:E1:C6:D9:E2

            X509v3 Subject Key Identifier: 
                88:4F:83:16:87:AD:AE:1E:FF:04:4A:79:66:92:C6:9F:62:69:4F:B1
            X509v3 Subject Alternative Name: 
                DNS:embed.ct.digicert.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl3.digicert.com/ssca-sha2-g3.crl

                Full Name:
                  URI:http://crl4.digicert.com/ssca-sha2-g3.crl

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.114412.1.1
                  CPS: https://www.digicert.com/CPS

            Authority Information Access: 
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt

            X509v3 Basic Constraints: critical
                CA:FALSE
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                                3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
                    Timestamp : Nov 13 16:57:03.632 2014 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:06:14:6A:E3:6D:0F:84:5D:6A:98:E7:29:
                                94:80:8B:F2:A4:23:85:68:4E:F9:BC:50:7C:FF:7B:94:
                                EB:20:54:82:02:21:00:91:63:83:FD:F6:31:5E:38:08:
                                AF:A7:5E:00:B7:0B:9B:1F:8B:FD:4D:7E:49:3C:43:E6:
                                64:E5:4B:F9:60:D7:89
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : 68:F6:98:F8:1F:64:82:BE:3A:8C:EE:B9:28:1D:4C:FC:
                                71:51:5D:67:93:D4:44:D1:0A:67:AC:BB:4F:4F:FB:C4
                    Timestamp : Nov 13 16:57:03.619 2014 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:61:4F:69:89:80:6A:62:2D:8E:A2:D0:24:
                                A5:E2:1D:74:67:51:77:C1:9B:DE:99:DE:16:56:2B:02:
                                77:A8:25:49:02:21:00:D3:41:6C:5D:88:40:F0:7A:FE:
                                E0:25:09:86:71:63:86:49:54:DD:96:E4:B5:9B:4A:84:
                                65:A9:25:12:F1:B7:E0
    Signature Algorithm: sha256WithRSAEncryption
         62:0c:d1:51:08:8a:a3:d1:df:bc:53:ba:e9:58:67:41:ea:5f:
         e3:51:f2:0b:9d:24:b4:77:6a:cf:96:ff:c5:ce:1c:55:1e:77:
         8a:49:46:7d:19:ef:52:4f:d3:24:b1:f2:95:60:67:40:d4:d1:
         f4:27:e4:66:55:45:c6:a5:51:a6:87:d0:09:af:f6:48:9b:df:
         24:c9:28:ad:47:b9:f6:a3:86:cb:64:64:3d:90:92:0e:94:f7:
         d2:8b:d6:79:b4:df:f2:3f:f5:6e:ea:08:b3:b0:37:87:a3:30:
         a7:f1:db:b7:86:b2:39:64:35:93:ee:5f:7b:01:51:5f:b1:e1:
         e0:d1:5d:a6:e6:a3:53:3f:66:97:16:8f:18:c4:fa:fc:8e:85:
         79:a1:95:7b:69:0b:f5:a4:92:1f:04:cf:ed:f6:95:e3:8f:b4:
         2a:6a:be:0c:a2:b6:53:99:5d:50:78:23:1c:fb:cb:2e:1d:be:
         b5:8d:83:2e:08:96:f8:c9:be:96:13:ed:61:0f:cf:57:44:ff:
         3a:d5:10:b0:bd:08:1f:27:c4:cf:97:17:e8:6a:62:bc:6d:e9:
         64:39:a0:36:79:d6:02:84:b7:47:26:9b:5d:b1:92:aa:f1:36:
         1a:31:9e:27:f2:25:54:89:17:ac:56:54:b0:e0:41:67:e4:b8:
         7b:e0:2c:88

Its not clear to me how to actually create one of these things if you are running a private PKI. There's support for the OID in OpenSSL:

$ grep -R "1.3.6.1.4.1.11129.2.4.2" *
crypto/objects/obj_dat.h:951,   /* OBJ_ct_precert_scts    1 3 6 1 4 1 11129 2 4 2 */
crypto/objects/objects.txt:1 3 6 1 4 1 11129 2 4 2  : ct_precert_scts   : CT Precertificate SCTs

And:

$ grep -R ct_precert_scts *
crypto/objects/obj_dat.h:0x2B,0x06,0x01,0x04,0x01,0xD6,0x79,0x02,0x04,0x02,/* [6191] OBJ_ct_precert_scts */
crypto/objects/obj_dat.h:{"ct_precert_scts","CT Precertificate SCTs",NID_ct_precert_scts,10,
crypto/objects/obj_dat.h:951,   /* "ct_precert_scts" */
crypto/objects/obj_dat.h:951,   /* OBJ_ct_precert_scts    1 3 6 1 4 1 11129 2 4 2 */
crypto/objects/obj_mac.num:ct_precert_scts      951
crypto/objects/objects.txt:1 3 6 1 4 1 11129 2 4 2  : ct_precert_scts   : CT Precertificate SCTs
crypto/x509v3/v3_scts.c:    {NID_ct_precert_scts, 0, NULL,
include/openssl/obj_mac.h:#define SN_ct_precert_scts    "ct_precert_scts"
include/openssl/obj_mac.h:#define LN_ct_precert_scts    "CT Precertificate SCTs"
include/openssl/obj_mac.h:#define NID_ct_precert_scts    951
include/openssl/obj_mac.h:#define OBJ_ct_precert_scts             1L,3L,6L,1L,4L,1L,11129L,2L,4L,2L

So there's presentation/display support, but NO example of how to use it in OpenSSL's self-documenting code. Typically, the self-documentation shows up in the <openssl src>/apps directory by way of a feature's use in subcommands.

There's an open question on the OpenSSL mailing list about it: How to add CT Precertificate SCTs to a server certificate?.

share|improve this answer
    
Can someone answer this in layman's terms? How do website owners remedy this problem? Do we need to buy a new certificate? If so, where do we get one? All my sites use Register.com SSL certs and ALL of them get this dreaded message scaring customers away! –  MC9000 Apr 21 at 23:17
    
Oh, in layman's terms: the bar to entry was just raised. If you are running a private PKI, then you are being corralled into buying a certificate from a participating CA. Participating CAs have to publish certified logs to show that they are issuing certificates for domains they are authorized. Also see the CT FAQ for the two other ways to comply. –  jww Apr 21 at 23:47
    
The problem exists because (1) CAs are not held responsible or accountable; and (2) we've experienced a number of CA failures in the past. The reason CAs are not responsible or accountable is because Browsers and CAs collude at the CA/Browser Forum. They make up the rules to suite their taste as they go (yes, the browsers are complicit). Browser security is such a joke... –  jww Apr 21 at 23:48
    
Looks like there is no way out of buying the more "expensive" certs, ugh! (this is ridiculous, if CA's are not accountable, then why are we getting raped for cert prices?! What are we paying for?! ) –  MC9000 Apr 23 at 3:46
    
If you're running a private PKI system, you'd have to spin up your own log server and add a command line flag to Chrome to trust it. Then you'd have to obtain a SCT from said log and then use the TLS extension to send it. –  StackExchange User May 9 at 16:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.