All geek questions in one place

Downloading a wildcard SSL certificate for Google App Engine gives "Confirmation of SSL certificate links outside of a managed domain."

I currently use a self-signed wildcard certificate (see http://pastie.org/8402240 ) in our Google Apps domain.

Let's say the domain is example.com. I have also registered the subdomains api.example.com and staging.example.com.

A self-signed certificate is for * .api.example.com.

It works great.

However, when I try to download a certificate signed by a CA (see http://pastie.org/8402243 ), I get an error: "The certificate of the SSL certificate is verified outside the managed domain."

A certificate signed by CA is a little more complicated, but it parses as http://pastie.org/8402255 , as well as for * .api.example.com (AND * .staging.example.com).

What happened to the CA certificate to cause this error?

+6
source share
4 answers

However, when I try to download a certificate signed by CA (see http://pastie.org/8402243 ), I get an error: "The subdomain of SSL certificate links is outside the managed domain."

I see two configuration problems. One of them is related to PKI, and the other is related to DNS.

I know that a PKI problem will cause problems for some user agents. I am not sure about the DNS problem, but it can be a problem because your error message refers to a "subdomain outside the managed domain". And they may not be the only problems.

The server certificate does not have an intermediate certificate required for verification. This is a well-known issue in PKI, and it is called the "which directory" problem. In this problem, the client does not know where to apply in order to receive the missing intermediate certificate, which was used to sign your certificate of the final object.

According to the CA-signed mouth ( 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

Your chain is missing the intermediate intermediate intermediate server tool "StartCom Class 2 Primary Intermediate Server CA".

You can get the missing intermediate link from Startcom CA certificates . The one you are looking for is sub.class2.server.ca.pem . A quick dump verifies that the sub.class2.server.ca.pem theme is the issuer of your server 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 happened to the CA certificate to cause this error?

After the certificate certificate is encoded in PEM, you must insert the following into the server certificate file. Essentially, your server certificate file will have two certificates.

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

Customers then need to β€œtrust” the Startcom root certificate ( CN=StartCom Certification Authority ). If they trust the Startcom root certificate, the server certificate checks:

 # Download Startcom 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 is another thing I noticed. Some hosts allow 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 do not allow correctly:

 $ 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 that you should have an address resource record similar to:

 api.soundtrackyourbrand.com. IN A 194.9.94.85

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

+1
source

I assume that you have configured your custom domain incorrectly. See Google using custom domain documentation, specifically the section on wildcard subdomains .

I assume you need to add:

  • soundtrackyourbrand.com
  • staging.soundtrackyourbrand.com
  • api.soundtrackyourbrand.com
  • *. Staging.soundtrackyourbrand.com
  • *. Api.soundtrackyourbrand.com

The list of user domains, because SSL contains many alternative object names.

0
source

Based on this error, it seems that the Google application is complaining that the certificate has subdomains that the Google App is not aware of about the business.

You mentioned that: * .staging.soundtrackyourbrand.com is included. Make sure the Google app is aware of this subdomain / zone (as well as soundtrackyourbrand.com), so it knocks you down.

The areas you need are as follows:

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

If you cannot add these entries, you will need to restore a certificate that is more specific to your zone.

Alternatively, you may not properly configure your first zone. For example, soundtrackyourbrand.com should be your only zone with api.soundtrackyourbrand.com and staging.soundtrackyourbrand.com being records.

0
source

Google applications only support a sub-domain of swap level substitution, * .api and * .staging.soundtrackyourbrand.com is a two-level

0
source

Source: https://habr.com/ru/post/955935/

More articles:


All Articles