I have a domain with a wildcard SSL certificate (https://domainA.com). I have users who use custom subdomains (https://user1.domainA.com). I have users who wish to use custom domains that point to their subdomains (CNAME records from https://domainB.com to https://user1.domainA.com).
The problem with these custom domains is that they throw an SSL warning in the browser, as the domain name on the SSL certificate (https://*.domainA.com) does not match the domain name being used to access the page (https://domainB.com).
Enter Cloudflare.
By using Cloudflare's Full SSL service, on https://domainB.com, I can suppress the SSL warning so users experience no problems. I know that the SSL warning exists (as disabling Cloudflare will cause the warning to re-appear), but Cloudflare silently dismisses the warning and proceeds with the encryption.
Also, by using Full SSL, I am theoretically encrypting traffic completely between the user and the server.
My question has to do with the security/legitimacy of this solution, to apply SSL encryption any domains (https://domainB.com, https://domainC.com) that users may wish to use to reach their pages (https://user1.domainA.com).
Is this secure? Is this safe? Is this responsible?
There are a few factors to this.
One is how far you trust CloudFlare. They will see your users' traffic in plaintext, after decrypting the tunnel between them and the user and before re-encrypting it to the origin server.
Secondly, CloudFlare are not doing any validation of the server's certificate with the Full SSL (non-strict) option. This means that it's not just about domain matching: none of the cert attributes: issuer, time range et al are checked.
Hence, someone can do a Man-in-the-middle attack between CloudFlare and you.
So, I wouldn't say it's very safe or secure, but it really depends on the type of data passing on your HTTPs channel.
It might be worth considering HTTP 301 redirect from https://domainB.com to https://userX.domainA.com rather than going for CNAME records, and using CloudFlare's Full (strict) SSL, if you're strongly concerned about your users' data.
Related
I just installed a Cloudflare Origin CA ssl certificate on my server. Because I have many domains on this server, I configured the certificate to protect them all, so I can use only one certificate for all my domains (domain1.com, domain2.com, etc...).
I went to check my ssl was working properly with the service whynopadlock.com, and I realized this service can list ALL of my domain names on the server by just accessing domain1.com? Are all the domains in a certificate meant to be public, is this normal behavior and can I avoid it?
I also noticed whynopadlock.com lists some domains in the certificate that are not mine. Does it mean Cloudflare is using the same certificate for many different users?
Are all the domains in a certificate meant to be public, is this normal behavior and can I avoid it?
All certificate subject alternate names are part of the certificate and are sent to every client that tries to connect securely.
There is no way to avoid it unless you want to use separate certificates for each domain.
I also noticed whynopadlock.com lists some domains in the certificate that are not mine.
Cloudflare states that this is normal:
Are Cloudflare SSL certificates shared?
Universal SSL certificates are shared across multiple domains for
multiple customers. If certificate sharing is a concern, Cloudflare
recommends a Dedicated or Custom SSL certificate.
Note that Cloudflare (as of Feb 2019) does provide dedicated certificates if you do not want to use a shared certificate.
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 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/
I have domain mydomain.com. I need use subdomains such test1.mydomain.com, helloworld.mydomain.com. These subdomains just host names in IIS bindings for my main site. Users of my sites can add subdomains. Is it possible to use one certificate for all subdomains and main domain? How can I test it with self signed sertificate?
Thanks!
Typically a standard SSL Certificate is issued to a single Fully Qualified Domain Name only, which means it can be used only to secure the exact domain to which it has been issued. With the Wildcard SSL option activated you expand what's possible by receiving an SSL Certificate issued to .domain.com. So if you apply for ".mydomain.com" it will secure "anything.mydomain.com"
Not quite sure on how to do it with self-signed certificates. Hope this info helps.
You will need to use a wild-card certificate eg
http://www.rapidssl.com/buy-ssl/wildcard-ssl-certificate/index.html
Once all the domains are in effect alliasses of the main domain there should be no problem here.
I dont know much about self signing certificates - except that they seem to be more trouble than they are worth. for less than $10 you can get a cert (not wildcard) from someone like CheapSSLs and test with this if you want - it will just throw an error about the name of the domain not matching the certificate
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.