7

I was looking at Google's Internet Authority G2. Its a subordinate CA (critical, CA:TRUE, pathlen:0) certified by GeoTrust. The dump is below.

Presumably, GeoTrust certified that CA for Google so Google can manage its web properties (corrections, please). However, the subordinate lacks a name constraint so that Google can mint certificates for any web property, and not just the ones it owns.

Both the IETF and CA/B Forums have name constraints that could be used to enforce the policy (rather than allowing an organization to mint certificates for any web property). The relevant documents are RFC 5280, 4.2.1.10 Name Constraints and Baseline Requirements, 9.7 Technical Constraints in Subordinate CA Certificates via Name Constraints.

Often, lack of a name constraint in a subordinate CA is of minimum concern because there's an independent third party reseller acting as an auditor that's assessing the validity of the signing request. But in this case, there is no independent reseller acting as auditor and there is no separation of concerns.

GeoTrust is owned by Symantec, and Symantec is a member of the CA/Browser Forums.

Why does the subordinate CA lack the name constraints? Should name constraints be present on the subordinate CA in this case?

$ openssl x509 -in google-g2.pem -inform PEM -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 146038 (0x23a76)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
        Validity
            Not Before: Apr  5 15:15:55 2013 GMT
            Not After : Dec 31 23:59:59 2016 GMT
        Subject: C=US, O=Google Inc, CN=Google Internet Authority G2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9c:2a:04:77:5c:d8:50:91:3a:06:a3:82:e0:d8:
                    50:48:bc:89:3f:f1:19:70:1a:88:46:7e:e0:8f:c5:
                    f1:89:ce:21:ee:5a:fe:61:0d:b7:32:44:89:a0:74:
                    0b:53:4f:55:a4:ce:82:62:95:ee:eb:59:5f:c6:e1:
                    05:80:12:c4:5e:94:3f:bc:5b:48:38:f4:53:f7:24:
                    e6:fb:91:e9:15:c4:cf:f4:53:0d:f4:4a:fc:9f:54:
                    de:7d:be:a0:6b:6f:87:c0:d0:50:1f:28:30:03:40:
                    da:08:73:51:6c:7f:ff:3a:3c:a7:37:06:8e:bd:4b:
                    11:04:eb:7d:24:de:e6:f9:fc:31:71:fb:94:d5:60:
                    f3:2e:4a:af:42:d2:cb:ea:c4:6a:1a:b2:cc:53:dd:
                    15:4b:8b:1f:c8:19:61:1f:cd:9d:a8:3e:63:2b:84:
                    35:69:65:84:c8:19:c5:46:22:f8:53:95:be:e3:80:
                    4a:10:c6:2a:ec:ba:97:20:11:c7:39:99:10:04:a0:
                    f0:61:7a:95:25:8c:4e:52:75:e2:b6:ed:08:ca:14:
                    fc:ce:22:6a:b3:4e:cf:46:03:97:97:03:7e:c0:b1:
                    de:7b:af:45:33:cf:ba:3e:71:b7:de:f4:25:25:c2:
                    0d:35:89:9d:9d:fb:0e:11:79:89:1e:37:c5:af:8e:
                    72:69
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E

            X509v3 Subject Key Identifier: 
                4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://g.symcb.com/crls/gtglobal.crl

            Authority Information Access: 
                OCSP - URI:http://g.symcd.com

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.11129.2.5.1

    Signature Algorithm: sha1WithRSAEncryption
         27:8c:cf:e9:c7:3b:be:c0:6f:e8:96:84:fb:9c:5c:5d:90:e4:
         77:db:8b:32:60:9b:65:d8:85:26:b5:ba:9f:1e:de:64:4e:1f:
         c6:c8:20:5b:09:9f:ab:a9:e0:09:34:45:a2:65:25:37:3d:7f:
         5a:6f:20:cc:f9:fa:f1:1d:8f:10:0c:02:3a:c4:c9:01:76:96:
         be:9b:f9:15:d8:39:d1:c5:03:47:76:b8:8a:8c:31:d6:60:d5:
         e4:8f:db:fa:3c:c6:d5:98:28:f8:1c:8f:17:91:34:cb:cb:52:
         7a:d1:fb:3a:20:e4:e1:86:b1:d8:18:0f:be:d6:87:64:8d:c5:
         0a:25:42:51:ef:b2:38:b8:e0:1d:d0:e1:fc:e6:f4:af:46:ba:
         ef:c0:bf:c5:b4:05:f5:94:75:0c:fe:a2:be:02:ba:ea:86:5b:
         f9:35:b3:66:f5:c5:8d:85:a1:1a:23:77:1a:19:17:54:13:60:
         9f:0b:e1:b4:9c:28:2a:f9:ae:02:34:6d:25:93:9c:82:a8:17:
         7b:f1:85:b0:d3:0f:58:e1:fb:b1:fe:9c:a1:a3:e8:fd:c9:3f:
         f4:d7:71:dc:bd:8c:a4:19:e0:21:23:23:55:13:8f:a4:16:02:
         09:7e:b9:af:ee:db:53:64:bd:71:2f:b9:39:ce:30:b7:b4:bc:
         54:e0:47:07
Improve this question
2
  • 1
    Since Google does not only own google.com, but also other domains (like gmail.com and google.whatever_TLD), I think having name constraints might be difficult. In addition, they might not want to have to buy a new sub CA each time they acquire a new domain.
    – user2313067
    Commented Apr 5, 2015 at 6:40
  • 2
    "... they might not want to have to buy a new sub CA each time they acquire a new domain" - Cry me a river :) I don't want to trust any old organization who pays GeoTrust money for the service :)
    – user29925
    Commented Apr 6, 2015 at 0:49

4 Answers 4

Reset to default
2

The structure is all wrong.

If Google uses this intermediate cert only for signing Google-owned domains (which I think is the case) they can't do it with a restricted path certificate, because they need to sign google.com and google.co.uk and gmail.com and even com.google now that they own that TLD.

In my opinion, the PKI was poorly designed to begin with, and there's no fixing it without starting over from scratch with something a bit more restricted and hierarchical like dnssec.

Improve this answer
10
  • 4
    I'm not sure DNSSEC is the answer. DNSSEC would require us to trust the registrars (e.g. firms like GoDaddy), the TLD's (e.g. VeriSign), and the root (e.g. ICANN), forever. I'm not sure I trust these entities any more than I trust the CA's. See Moxie Marlinspike's blog post for a great write-up on this subject: thoughtcrime.org/blog/ssl-and-the-future-of-authenticity
    – mti2935
    Commented Apr 5, 2015 at 23:48
  • 1
    If only DNSSec didn't require very weak RSA keys... and if only it supported faster/better crypto like EC....
    – makerofthings7
    Commented Apr 6, 2015 at 0:30
  • 1
    @makerofthings7-C.Lamont yes, DNSSec in it's current form probably won't cut it. And progress is moving along at glacial (almost congressional) speed. But using EC signatures would make for much smaller keys, which would help quite a lot.
    – tylerl
    Commented Apr 6, 2015 at 0:37
  • 2
    Do you know of anything "better" than the current DNSSec? Either a modified RFC, or something redone from the ground up?
    – makerofthings7
    Commented Apr 6, 2015 at 0:38
  • 1
    @makerofthings7-C.Lamont: The Perspectives project at Carnegie Mellon University looks promising. See perspectives-project.org. Or, Moxie Marlinspikes's Convergence project, which is basically Perspectives with some additions, also seems like a step in the right direction. See youtube.com/watch?v=Z7Wl2FW2TcA.
    – mti2935
    Commented Apr 6, 2015 at 10:14
1

It's possible that this CA certificate is linked to GeoTrust's root certificate by way of Geotrust's 'GeoRoot' service, which "Allows Organizations with Their Own Certificate Authority (CA) to Chain to GeoTrust's Ubiquitous Public Root ". See http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html.

Improve this answer
5
  • Oh, thanks for that. I was not aware that happened. Bug filed against Mozilla: GeoTrust and Ubiquitous CA Public Root program.
    – user29925
    Commented Apr 5, 2015 at 21:54
  • Very well spelled out. These are my thoughts exactly. I'll be curious to see the response to this. I think Mozilla (and other browsers) are in a damned if you do, damned if you don't situation here. If they drop Geotrust's root certificate from their set of trusted certificates, it will break the trust for millions of sites on the internet. If they continue to trust Geotrust's root certificate, it opens the way for a bad actor to start 'minting' (as you put it) bogus certificates for any site by abusing the 'GeoRoot' program. Just another example of how broken SSL has become.
    – mti2935
    Commented Apr 5, 2015 at 22:08
  • I just took a gander at Google's Certification Practices Statement (at bit.ly/1yaBOMD). If they are actually playing by these rules, then it seems that they are exercising at least as much diligence as a reseller of GeoTrust's CA services would. Hopefully GeoTrust requires all participants in its GeoRoot program to adhere to these policies. But notwithstanding, it just takes one proverbial bad apple. The underlying problem here is that we can't (viably) revoke our trust in GeoTrust without breaking millions of sites on the internet.
    – mti2935
    Commented Apr 5, 2015 at 23:58
  • Yeah, but the problem here is the disinterested third party auditor that performs the verifications is no longer present in the process. It sounds like the inmates are now running the asylum :) Google is less of a worry for me; any old organization (like the Islamic Republic of Iran) seems to be a bigger problem.
    – user29925
    Commented Apr 6, 2015 at 0:07
  • 1
    I hope that GeoTrust will not allow the Islamic Republic of Iran to participate in its GeoRoot program. But, I think we're basically saying the same thing here.
    – mti2935
    Commented Apr 6, 2015 at 0:35
1

I think you are assuming Google is not trusted or that this is an oversight in the Certificate Authority trust model.

I don't think there is a problem with Google running a certificate authority. Perhaps they can choose to constrain it to their own domains, but nothing stops them from entering into an agreement with an established Root CA (or buying on!) and being a public signing CA.

If they demonstrate appropriate security and process, they should be free to issue any certificate to a validated identity.

Improve this answer
0

Why does the subordinate CA lack the name constraints?

Because browsers would ignore these settings anyway. Currently there is no technical way to restrict which certificates sub-CAs can issue.

Improve this answer
3
  • Two things come to mind: user agents like browsers are just one class of software that consumes PKIX certificates. And I'm not sure Browsers ignore it since its codified at the CA/B Forums. (If it was only written in the IETF, then I would agree with you).
    – user29925
    Commented Apr 5, 2015 at 22:56
  • 1
    According to code.google.com/p/chromium/issues/detail?id=407093 Apples Secure Transport does not support name constraints and thus Safari and Chrome on OS X don't. Firefox might support NC in current versions, at least bugs in this area where fixed a year ago: bugzilla.mozilla.org/show_bug.cgi?id=962760. But it is probably not a feature one can use as a critical constraint currently. And when used as non-critical it simply could be ignored.
    – Steffen Ullrich
    Commented Apr 7, 2015 at 14:33
  • Some browsers (Safari) ignore name constraints. Other browsers will validate them if they are listed. If the name constraint is not marked as a "critical" section, the certificate continues to work in clients that ignore name constraints.
    – Gabe
    Commented Apr 19, 2015 at 17:46

You must log in to answer this question.