3

I am using Amazon EC2 ELB and following their recommendation of using CNAME to refer to the public DNS of the ELB:

$ nslookup qa.mydomain.com
Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
qa.mydomain.com canonical name = mydomain-20530xxxx.us-west-1.elb.amazonaws.com.
Name:   mydomain-20530xxxx.us-west-1.elb.amazonaws.com
Address: 50.18.xxx.yyy

I purchased a wildcard SSL cert to protect all my subdomains. So the cert was issued for *.mydomain.com. However, when I visit qa.mydomain.com, all browsers are screaming security. The message on Google Chrome, when I try to access https://qa.mydomain.com is:

Chrome says: You attempted to reach mydomain-20530xxxx.us-west-1.elb.amazonaws.com, but instead you actually reached a server identifying itself as *.mydomain.com. This may be caused by a misconfiguration on the server or by something more serious..

Am I going about it the wrong way? Is the use of CNAME essentially incompatible with PKI/SSL? What are my options?

Thanks.

PS: Here is the report from performing dig on the address: qa.mydomain.com. Obviously, the actual domain name and results have been masked for security.

$ dig qa.mydomain.com

; <<>> DiG 9.8.1-P1 <<>> qa.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 961
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;qa.mydomain.com.       IN  A

;; ANSWER SECTION:
qa.mydomain.com.    1670    IN  CNAME   mydomain-205300xxxx.us-west-1.elb.amazonaws.com.
mydomain-205300xxxx.us-west-1.elb.amazonaws.com. 60 IN A 50.18.xxx.yyy

;; Query time: 105 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug  9 14:05:31 2012
;; MSG SIZE  rcvd: 121
Raj
  • 2,852
  • 4
  • 29
  • 48

1 Answers1

4

Whether the IP address resolution comes from a CNAME or an A DNS entry has no influence on the certificate name verification.

What matters is that the name, as you request it in the URL, matches one of the entries in the certificate.

In short, if the certificate has Subject Alternative Name entries, one of them must match the host name you request; if there are no SAN DNS entries, the Common Name (CN) of the Subject DN must match the host name.

Bruno
  • 119,590
  • 31
  • 270
  • 376
  • Thanks for the response, Bruno. Does that mean that wildcard SSLs just cannot work with CNAME given that the common name is *.mydomain.com? – Raj Aug 09 '12 at 20:27
  • That's not at all what I said: CNAME and wildcards are not related at all. If you don't have any SAN and if the CN is `*.mydomain.com`, `https://something.mydomain.com` will work. – Bruno Aug 09 '12 at 20:30
  • Something does not add up. I have a certificate issued to *.mydomain.com. I have CNAME mapping to my Amazon-provided name. When I go to https://qa.mydomain.com, both Safari and Google Chrome give me a bad certificate. Chrome says: You attempted to reach rmydomain-20530xxxx.us-west-1.elb.amazonaws.com, but instead you actually reached a server identifying itself as *.mydomain.com. This may be caused by a misconfiguration on the server or by something more serious... – Raj Aug 09 '12 at 20:34
  • You're almost certainly using an incorrect indirection instead of (or in combination with) your CNAME. Check with `dig` or any DNS querying tool that `qa.mydomain.com` ends up pointing to the correct IP address. – Bruno Aug 09 '12 at 20:49
  • Hi Bruno, Thanks for your continued help. The snippet I posted is by doing nslookup on qa.mydomain.com. I am updating my question with the (anonymized) dig report. – Raj Aug 09 '12 at 21:06
  • 2
    This looks fine. Check with Chrome's Developer Tools, or Firefox with Firebug/HttpFox whether there's an HTTP redirection happening after an initial connection to `https://qa.mydomain.com`. This is probably a server configuration issue. – Bruno Aug 09 '12 at 21:16
  • Bruno, redirection it was indeed. Thanks for your insights! – Raj Aug 09 '12 at 21:24
  • `DIG` is `Domain Information Groper`; an improvement on `nslookup` for linux systems; though is available via third party for Windows. More info on the latter here: https://www.danesparza.net/2011/05/using-the-dig-dns-tool-on-windows-7/ – JohnLBevan Aug 01 '17 at 10:30