Uploading wildcard SSL certificate for Google App Engine gives "The SSL certificate references subdomain outside of managed domain."

Question

I am currently using a self signed wildcard certificate (see http://pastie.org/8402240) at our Google Apps domain.

Lets say the domain is example.com. I have also registered the subdomains api.example.com and staging.example.com.

The self signed certificate is for *.api.example.com.

It works just fine.

When I try to upload a CA signed certificate, however (see http://pastie.org/8402243) I get the error message "The SSL certificate references subdomain outside of managed domain."

The CA signed certificate is a bit more complex, but it parses as http://pastie.org/8402255, and it too is for *.api.example.com (AND *.staging.example.com).

What is wrong with the CA certificate to cause this error?

Answer 1

When I try to upload a CA signed certificate, however (see http://pastie.org/8402243) I get the error message "The SSL certificate references subdomain outside of managed domain."

I see two problems with the configuration. One is PKI related, and the other is DNS related.

I know the PKI issue will cause problems in some User Agents. I'm not sure about the DNS problem, but it could be the issue because your error message references " subdomain outside of managed domain". And they may not be the only problems.

---

The server's certificate is missing an intermediate certificate required for verification. That's a well known problem in PKI, and its called the "which directory" problem. In this problem, a client does not know where to go to get the missing intermediate certificate that was used to sign your end-entity certificate.

According to the CA-signed pastie (http://pastie.org/8402243):

$ openssl x509 -in 8402243.pem -inform PEM -noout -text 

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 108388 (0x1a764)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA
        Validity
            Not Before: Oct  3 05:15:45 2013 GMT
            Not After : Oct  4 10:34:27 2015 GMT
        Subject: C=SE, ST=Stockholm, L=Stockholm, O=S.Biz AB, CN=api.example.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a9:76:dc:c7:5c:1a:ab:cf:dc:0b:6d:4b:1a:83:
                    ...
                    7e:45:cb:cc:9f:14:e4:6c:b9:22:fa:d8:0f:5c:69:
                    76:2b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment, Key Agreement
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Subject Key Identifier: 
                FC:EE:69:80:9D:A1:0C:43:C6:24:CE:85:F6:00:C9:65:CD:4A:AF:D4
            X509v3 Authority Key Identifier: 
                keyid:11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86

            X509v3 Subject Alternative Name: 
                DNS:api.example.com, DNS:example.com, DNS:staging.example.com, DNS:*.staging.example.com, DNS:*.api.example.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.2
                Policy: 1.3.6.1.4.1.23223.1.2.3
                  CPS: http://www.startssl.com/policy.pdf
                  User Notice:
                    Organization: StartCom Certification Authority
                    Number: 1
                    Explicit Text: This certificate was issued ...

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.startssl.com/crt2-crl.crl

            Authority Information Access: 
                OCSP - URI:http://ocsp.startssl.com/sub/class2/server/ca
                CA Issuers - URI:http://aia.startssl.com/certs/sub.class2.server.ca.crt

            X509v3 Issuer Alternative Name: 
                URI:http://www.startssl.com/
    Signature Algorithm: sha256WithRSAEncryption
         97:2c:96:ee:80:ca:1f:27:55:e0:60:68:6b:5e:ea:44:a7:bb:
         ...
         64:6e:1a:0b:9b:bd:10:e6:ac:48:60:cd:51:ac:46:57:fa:61:
         13:32:65:a5

You are missing the "StartCom Class 2 Primary Intermediate Server CA" intermediate in your chain.

You can get the missing intermediate from Startcom's CA certs. The one you are looking for is sub.class2.server.ca.pem. A quick dump verifies the subject of sub.class2.server.ca.pem is the issuer of your server's certificate:

$ openssl x509 -in sub.class2.server.ca.pem -inform PEM -noout -text 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 26 (0x1a)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Certification Authority
        Validity
            Not Before: Oct 24 20:57:09 2007 GMT
            Not After : Oct 24 20:57:09 2017 GMT
        Subject: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA
    ...

What is wrong with the CA certificate to cause this error?

You should paste the following into your server's certificate file, after the PEM encoded server certificate. Essentially, your server's certificate file will have two certs in it.

-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NzA5WhcNMTcxMDI0MjA1NzA5WjCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4k85L6GMmoWtCA4IPlfyiAEh
G5SpbOK426oZGEY6UqH1D/RujOqWjJaHeRNAUS8i8gyLhw9l33F0NENVsTUJm9m8
H/rrQtCXQHK3Q5Y9upadXVACHJuRjZzArNe7LxfXyz6CnXPrB0KSss1ks3RVG7RL
hiEs93iHMuAW5Nq9TJXqpAp+tgoNLorPVavD5d1Bik7mb2VsskDPF125w2oLJxGE
d2H2wnztwI14FBiZgZl1Y7foU9O6YekO+qIw80aiuckfbIBaQKwn7UhHM7BUxkYa
8zVhwQIpkFR+ZE3EMFICgtffziFuGJHXuKuMJxe18KMBL47SLoc6PbQpZ4rEAwID
AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
VR0OBBYEFBHbI0X9VMxqcW+EigPXvvcBLyaGMB8GA1UdIwQYMBaAFE4L7xqkQFul
F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov
L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl
LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEAnQfh7pB2MWcWRXCMy4SLS1doRKWJwfJ+
yyiL9edwd9W29AshYKWhdHMkIoDW2LqNomJdCTVCKfs5Y0ULpLA4Gmj0lRPM4EOU
7Os5GuxXKdmZbfWEzY5zrsncavqenRZkkwjHHMKJVJ53gJD2uSl26xNnSFn4Ljox
uMnTiOVfTtIZPUOO15L/zzi24VuKUx3OrLR2L9j3QGPV7mnzRX2gYsFhw3XtsntN
rCEnME5ZRmqTF8rIOS0Bc2Vb6UGbERecyMhK76F2YC2uk/8M1TMTn08Tzt2G8fz4
NVQVqFvnhX76Nwn/i7gxSZ4Nbt600hItuO3Iw/G2QqBMl3nf/sOjn6H0bSyEd6Si
BeEX/zHdmvO4esNSwhERt1Axin/M51qJzPeGmmGSTy+UtpjHeOBiS0N9PN7WmrQQ
oUCcSyrcuNDUnv3xhHgbDlePaVRCaHvqoO91DweijHOZq1X1BwnSrzgDapADDC+P
4uhDwjHpb62H5Y29TiyJS1HmnExUdsASgVOb7KD8LJzaGJVuHjgmQid4YAjff20y
6NjAbx/rJnWfk/x7G/41kNxTowemP4NVCitOYoIlzmYwXSzg+RkbdbmdmFamgyd6
0Y+NWZP8P3PXLrQsldiL98l+x/ydrHIEH9LMF/TtNGCbnkqXBP7dcg5XVFEGcE3v
qhykguAzx/Q=
-----END CERTIFICATE-----

Clients are then required to "trust" Startcom's root certificate (CN=StartCom Certification Authority). If they trust Startcom's root certificate, then your server certificate will verify:

# Download Startcom's roots
$ wget https://www.startssl.com/certs/ca-bundle.pem
--2014-02-07 05:08:52--  https://www.startssl.com/certs/ca-bundle.pem
...

# Verify the server certificate using the Startcom root
$ openssl verify -CAfile ca-bundle.pem 8402243+intermediate.pem
8402243+intermediate.pem: OK

---

Here's one other thing I noticed. Some hosts are resolving OK:

$ dig staging.soundtrackyourbrand.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> staging.soundtrackyourbrand.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22761
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;staging.soundtrackyourbrand.com. IN    A

;; ANSWER SECTION:
staging.soundtrackyourbrand.com. 3599 IN A  194.9.94.85
staging.soundtrackyourbrand.com. 3599 IN A  194.9.94.86

But some hosts are not resolving properly:

$ dig api.soundtrackyourbrand.com

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> api.soundtrackyourbrand.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33966
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;api.soundtrackyourbrand.com.   IN  A

;; AUTHORITY SECTION:
soundtrackyourbrand.com. 1755   IN  SOA ns1.loopia.se. registry.loopia.se. 1391644800 10800 3600 604800 86400

;; Query time: 0 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Fri Feb  7 05:30:05 2014
;; MSG SIZE  rcvd: 103

I believe you should have an address resource record similar to:

api.soundtrackyourbrand.com.    IN    A   194.9.94.85

Or, make it a sub-domain by providing a Start of Authority (SOA) record. But I'm not sure how Google will handle it in its verification routines, so it might be easier to just give it an address resource record.