我目前在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证书有什么问题?
答案 0 :(得分:1)
但是,当我尝试上传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主要中间服务器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编码的服务器证书。从本质上讲,您的服务器的证书文件中将包含两个证书。
-----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-----
然后客户需要信任" 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
这是我注意到的另一件事。有些主机正在解决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将如何在其验证例程中处理它,因此可能更容易为其提供地址资源记录。
答案 1 :(得分:0)
我的猜测是您没有正确设置自定义域。请参阅Google's Using a Custom Domain documentation, specifically the section on Wildcard Subdomain Mapping。
我猜你需要添加:
到自定义域列表,因为SSL包含相当多的主题备用名称。
答案 2 :(得分:0)
根据错误,Google App似乎抱怨该证书包含Google App无法了解的子域名。
您提到:* .staging.soundtrackyourbrand.com包含在内。确保Google App知道此子域/区域(以及soundtrackyourbrand.com),因为这就是为什么它会让您失望。
您需要拥有的区域是:
如果您无法添加这些记录,则需要重新生成更适合您所在区域的证书。
或者,您可能错误地设置了第一个区域。例如,soundtrackyourbrand.com应该是您的唯一区域,其中包含api.soundtrackyourbrand.com&amp; staging.soundtrackyourbrand.com是A记录。
答案 3 :(得分:0)
Google应用仅支持一级通配符子域,* .api和* .staging.soundtrackyourbrand.com是两级