为 Google App Engine 上传通配符 SSL 证书会给出“SSL 证书引用托管域之外的子域”。答案

【问题标题】：Uploading wildcard SSL certificate for Google App Engine gives "The SSL certificate references subdomain outside of managed domain."为 Google App Engine 上传通配符 SSL 证书会给出“SSL 证书引用托管域之外的子域”。
【发布时间】：2013-10-22 12:56:59
【问题描述】：

我目前在我们的 Google Apps 域中使用自签名通配符证书（请参阅 http://pastie.org/8402240）。

假设域是 example.com。我还注册了子域 api.example.com 和 staging.example.com。

自签名证书适用于 *.api.example.com。

效果很好。

但是，当我尝试上传 CA 签名证书时（请参阅 http://pastie.org/8402243），我收到错误消息“SSL 证书引用托管域之外的子域。”

CA 签名证书有点复杂，但它解析为http://pastie.org/8402255，它也适用于 *.api.example.com (AND *.staging.example.com)。

导致此错误的 CA 证书有什么问题？

【问题讨论】：

标签： google-app-engine ssl certificate ssl-certificate google-apps

【解决方案1】：

我的猜测是您没有正确设置自定义域。见Google's Using a Custom Domain documentation, specifically the section on Wildcard Subdomain Mapping。

我猜你需要添加：

soundtrackyourbrand.com
staging.soundtrackyourbrand.com
api.soundtrackyourbrand.com
*.staging.soundtrackyourbrand.com
*.api.soundtrackyourbrand.com

到自定义域列表，因为 SSL 包含相当多的主题备用名称。

【讨论】：

这可能不是这种情况，因为自签名证书只适用于 *.api.soundtrackyourbrand.com，对吧？

【解决方案2】：

根据该错误，Google App 似乎在抱怨证书包含 Google App 不知道的子域。

您提到：*.staging.soundtrackyourbrand.com 包括在内。确保 Google App 知道这个子域/区域（以及 soundtrackyourbrand.com），因为这就是它让您退缩的原因。

您需要拥有的区域是：

soundtrackyourbrand.com
staging.soundtrackyourbrand.com
api.soundtrackyourbrand.com

如果您无法添加这些记录，则需要重新生成更适合您所在区域的证书。

或者，您的第一个区域可能设置不正确。例如，soundtrackyourbrand.com 应该是您的only 区域，其中 api.soundtrackyourbrand.com 和 staging.soundtrackyourbrand.com 是 A 记录。

【讨论】：

正如我对 Michael Pasqualone 所说的那样 - 区域和名称对于自签名证书来说不是问题，所以我怀疑是这种情况吗？

【解决方案3】：

但是，当我尝试上传 CA 签名证书时（请参阅 http://pastie.org/8402243），我收到错误消息“SSL 证书引用托管域之外的子域。”

我发现配置有两个问题。一个是 PKI 相关的，一个是 DNS 相关的。

我知道 PKI 问题会导致某些用户代理出现问题。我不确定 DNS 问题，但这可能是问题所在，因为您的错误消息引用了“托管域之外的子域”。它们可能不是唯一的问题。

服务器的证书缺少验证所需的中间证书。这是 PKI 中众所周知的问题，称为“哪个目录”问题。在此问题中，客户端不知道去哪里获取丢失的用于签署最终实体证书的中间证书。

根据 CA 签名的粘贴 (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/emailAddress=hostmaster@example.com
        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

您的链中缺少“StartCom Class 2 Primary Intermediate Server CA”中间体。

您可以从 Startcom 的CA certs 获取缺少的中间体。您正在寻找的是sub.class2.server.ca.pem。快速转储验证sub.class2.server.ca.pem 的主题是您服务器证书的颁发者：

$ 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
    ...

导致此错误的 CA 证书有什么问题？

您应该将以下内容粘贴到服务器的证书文件中， PEM 编码的服务器证书之后。本质上，您的服务器的证书文件将包含两个证书。

然后要求客户端“信任”Startcom 的根证书 (CN=StartCom Certification Authority)。如果他们信任 Startcom 的根证书，那么您的服务器证书将验证：

# 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

这是我注意到的另一件事。一些主机解析正常：

$ 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

但有些主机没有正确解析：

$ 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

我相信你应该有一个类似的地址资源记录：

api.soundtrackyourbrand.com.    IN    A   194.9.94.85

或者，通过提供授权开始 (SOA) 记录使其成为子域。但我不确定 Google 将如何在其验证例程中处理它，因此只给它一个地址资源记录可能会更容易。

【讨论】：

【解决方案4】：

Google 应用只支持一级通配符子域，*.api 和 *.staging.soundtrackyourbrand.com 是二级

【讨论】：