I have a site that has subdomains for each user and a wildcard SSL Cert
https://user1.mysite.com
https://user2.mysite.com
The question is can someone set a cname record such as user1.theirsite.com -> user1.mysite.com and have it still use https?
Will it work if they install a SSL Cert on their server to secure the connection?
Thanks
The best way for this to work is if they arrange with you to have your SSL certificate include their "alias" as a Subject Alternate Name extension in your X.509 certificate.
This is the approach used by some CDNs when they host https sites for clients - they put all of the known site names that are hosted on one server in one large SSL certificate, and then the clients use CNAMEs to point their domain at the right CDN server.
The host name and certificate verification (and in fact, checking that SSL is used at all) are solely the responsibility of the client.
The host name verification will be done by the client, as specified in RFC 2818, based on the host name they request in their URL. Whether the host name DNS resolution is based on a CNAME entry or anything else is irrelevant.
If users are typing https://user1.theirsite.com/ in their browser, the certificate on the target site should be valid for user1.theirsite.com.
If they have their own server for user1.theirsite.com, different to user1.mysite.com, a DNS CNAME entry wouldn't make sense. Assuming the two hosts are effectively distinct, they could have their own valid certificate for user1.theirsite.com and make a redirection to https://user1.theirsite.com/. The redirection would also be visible in the address bar.
If you really wanted to have a CNAME from user1.theirsite.com to user1.mysite.com, they might be able to give you their certificate and private key so that you host it on your site too, using Server Name Indication (assuming same port, and of course same IP address since you're using a CNAME). This would work for clients that support SNI. There would however be a certain risk to them in giving you their private keys (which isn't generally recommended).
The following is set up and working:
DNS entry for a.corp.com -> CNAME b.corp2.com -> A 1.2.3.4
The haproxy at 1.2.3.4 will serve up the cert for a.corp.com and the site loads fine from a webserver backend.
So, on your server you will need user1.theirsite.com cert and it will work.
Related
I observed a site example.com has a cname mapping with mysite.com. Both example.com and mysite.com have ssl certificates.
Correct if I am wrong?
When a browser tries to connect https://example.com it checks DNS and finds it has cname mapping with mysite.com and connect to mysite.com web server directly.
When I observed browser it has ssl certificate for example.com domain. I am facing problem in understanding this case.
If request did not go to example.com web server how could browser get ssl certificate of example.com
or my cname mapping understanding is wrong?
or example.com private and public keys are shared with mysite.com webserver ?
DNS and TLS operate completely independent of each other.
TLS is used, among other things like encryption, to verify the identity of a server against its FQDN (Fully qualified domain name). This is done by checking whether the server in question is able to present a certificate, containing the FQDN, signed by a trusted certification authority (CA).
DNS is used to resolve host names to IP addresses, in order to establish network connections (like TCP connections) on a lower layer. How this resolution takes place is completely transparent to other components, like TLS. It does not matter whether the name resolution involves A, AAAA, or the mentioned CNAME record - in our context the input is always a single hostname, the output is always one (or more) IP addresses. Intermediate results, like CNAME mappings, are essentially discarded once name resolution is done.
This means that the TLS client always uses the FQDN initially requested by the user, regardless of any CNAME mappings, to verify the certificate. How to present a valid certificate is up to the server - sticking to your example, the server behind FQDN mysite.com will have to present a certificate valid for example.com in order for the client to accept it. How the private/public key of this certificate is generated, and whether it is shared with other certificates or servers, does not matter.
We would have to explicitly attach the SSL certificates of both the domains to the webserver/load balancer for both the domains to support HTTPS.
To understand this, it's useful to be aware of and understand SNI
When multiple websites are hosted on one server and share a single IP
address, and each website has its own SSL certificate, the server may
not know which SSL certificate to show when a client device tries to
securely connect to one of the websites. This is because the SSL/TLS
handshake occurs before the client device indicates over HTTP which
website it's connecting to.
Server Name Indication (SNI) is designed to solve this problem. SNI is
an extension for the TLS protocol (formerly known as the SSL
protocol), which is used in HTTPS. It's included in the TLS/SSL
handshake process in order to ensure that client devices are able to
see the correct SSL certificate for the website they are trying to
reach. The extension makes it possible to specify the hostname, or
domain name, of the website during the TLS handshake, instead of when
the HTTP connection opens after the handshake.
From: https://www.cloudflare.com/en-gb/learning/ssl/what-is-sni/
This question already has answers here:
Is it possible to have SSL certificate for IP address, not domain name? [closed]
(7 answers)
Closed 11 months ago.
I wonder why I am getting certificate error if I try to access a site with ip address instead of domain name. Lets say for example nslookup says google.com is 173.194.43.96, so I tried to browse https://173.194.43.96 and I got certificate error saying that the security certificate presented by this website was issued for a different website's address. Why is that so?
This is because an SSL certificate is issued for a particular domain name. If the certificate name doesn't match the visited domain, the browser will show an error.
One of the main functions of SSL is to prove to the user that they are really connecting to the site they requested, and not to an attacker masquerading as the end site. Without linking the domain name to the certificate this would not be possible.
It is conceivable that the browser certificate system could have been designed to include the IP address in the certificate, but this would make it difficult to use DNS load balancing or even to change hosting providers, as a new certificate would have to be issued each time this happened. If the certificate included just the IP address and not the domain, this would leave the user defenseless against DNS spoofing attacks. So the only way forward really was to use the domain alone.
As a matter of interest, it is possible to obtain an SSL certificate for an IP address - and as Google is their own certificate authority, they could issue themselves a certificate for 173.194.43.96 and thus make it possible to browse google securely by ip address, so long as they used SNI to serve up the correct certificate. It seems implausible that this would be worth the additional complexity however...
This is a nice introduction to SSL if you want to read more:
https://timnash.co.uk/guessing-ssl-questions/
On MAC High Sierra and Python 3.6.4, I tried the solution: requests toolbelt:HostHeaderSSLAdapter 1st, unfortunately, it doesn't work for me, then I tried
forcediphttpsadapter, got it works finally.
The author explains everything in the readme part and has provided a sample script and it can be followed easily.
1.Install the library by pip install requests[security] forcediphttpsadapter
2.run the sample script:
import requests
from forcediphttpsadapter.adapters import ForcedIPHTTPSAdapter
session = requests.Session()
session.mount("https://example.com", ForcedIPHTTPSAdapter(dest_ip='1.2.3.4'))
response = session.get(
'/some/path', headers={'Host': 'example.com'}, verify=False)
Note: For some cases, you may need to remove the prefix: 'www' from the url.
What happens is that the certificate is issued to www.google.com, and not to its IP address. Hence, your browser won't be able to verify the certificate, which lists www.google.com as entity.
For more info, see: www.digicert.com/ssl-support/certificate-name-mismatch-error.htm
The Common Name is typically composed of Host + Domain Name and will look like www.yoursite.com or yoursite.com. SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a SSL Server Certificate for the domain domain.com will receive a warning if accessing a site named www.domain.com or secure.domain.com, as www.domain.com and secure.domain.com are different from domain.com.
I would like to generate an SSL Certificate Signing Request (CSR) for the procurement and installation of an SSL certificate.
My question surrounds what we should enter for the FQDN given our specific situation
We will be hosting a domain name 'www.foo.com' within our server.
This domain will be accessed via a different domain 'www.bar.com' which will be CNAMEd to our hosted domain 'www.foo.com'
We want the client to see that the domain 'www.bar.com' has a valid SSL certificate.
So my question is, when we generate the CSR do we need to enter 'www.foo.com.' or 'www.bar.com.' as the FQDN for hostname in the CSR?
Edit: It is not intended that the domain name www.foo.com will ever be used to access the website.
Looking at this answer https://serverfault.com/questions/494654/which-fqdn-hostname-to-use-for-ssl-certificate-signing-request-when-using-a-cna it looks like in our CSR we should be using 'www.bar.com.' but confirmation from a suitably qualified person would be appreciated!
www.bar.com
Whatever FQDN the client requests in the browser should be in the subject of the certificate - no matter what happens in "the background", be that in terms of DNS resolution, backend proxying etc.
As long as the browser thinks it's talking to www.bar.com, the browser will also expect www.bar.com to be in the certificate
I am going to use an SSL certificate on my chat application based on XMPP(ejabberd) which is hosted on an IP.
So, I will be using the IP as the common name when I am generating my SSL certificate. But the server that has everything hosted on it, refers to the IP using a hostname as abcd.yourserver.net.
Therefore, I am confused as to if I have to use the IP or this weird hostname while generating my SSL certificate and if in future I decide to use a domain name instead of the IP for my application, will I have to buy a new SSl certificate or can I regenerate the old one. Also, can I change the type like wilcard or single certificate?
P.S. I have never bought an SSL certificate, so forgive me if the question is newbish.
When generating an SSL certificate for an XMPP server, you have to use the domain name of your XMPP service.
I am quite confused here:
I use DNSMadeeasy to manage my DNS. I have two apps.
One is Heroku hosted, and has https on https://example.com - Heroku has many great tutorials to setup the certificate, it hasn't been a problem.
The other one is a wordpress, hosted in 1and1 (though it shouldn't matter here), and is reachable at http://subdomain.example.com and we want it to be available at https://subdomain.example.com
1and1 does sell SSL certificate, but their automated setup works only when one uses their services for DNS also, as they say. Their support says it should be DNSMadeEasy which should be hosting our SSL certificate. I have the feeling it is not true, because for https://example.com, DNSMadeEasy was never involved.
Questions:
When does certificate querying occurs? Before, After, or in parallel of DNS resolution?
Who is hosting a certificate? The DNS provider? The server (accessible like a sitemap.xml at the root for instance)? A third party?
To enlarge the case, in general if I have a personal server with a fix IP, how can I communicate through https with a valid certificate?
In my case, how can I get my way out of it to make https://subdomain.example.com work?
You are right for not believing the 1and1 suggestion.
To answer your questions:
When does certificate querying occurs? Before, After, or in parallel
of DNS resolution?
A client resolves domain name to an IP address first. So DNS resolution happens first.
Who is hosting a certificate?
The server (in simplistic terms) hosts the certificate.
When a client wants to connect to your site (via HTTPS) it will first establish a secure connection with that IP address on port 443 (this is why usually (without SNI) you can only have one SSL certificate per IP address). As part of this process (which is called handshake) a client can also specify a server name (so-called server name extension) - this is a domain name of your site. This is useful if you have an SSL certificate that is valid for multiple domains.
A good/detailed explanation how it works can be found here
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
if I have a personal server with a fix IP, how can I communicate
through https with a valid certificate?
Your server will need to be able to respond on port 443 and have/host an SSL certificate for a domain that resolves to that IP address.
In my case, how can I get my way out of it to make
https://subdomain.example.com work?
You need to purchase a certificate for subdomain.example.com and install it on the wordpress server.
Usually in hosted solution like yours you have 2 options:
Buy the SSL certificate via the provider (1and1 in your case) - a simpler option, they will configure everything for you.
Buy the SSL certificate yourself. Here you will most likely need to login to your 1and1/Wordpress management interface and generate a CSR (essentially a certificate request). Then you purchase the SSL certificate using this CSR and then you can install it via the same management interface.
The process will look similar to this:
http://wpengine.com/support/add-ssl-site/