I have a website a.example which has an SSL certificate through CloudFlare.
I also have a website b.example which is pointing to a.example via an A record in the DNS (it points to the IP address of a.example).
When I visit b.example, I also want HTTPS, can I get it to work with my certificiate from a.example?
No. Certificates are per domain. You need either 2 certificates, each one with one name or a certificate with both names in it.
Otherwise if I replace in your question the two sites by Apple and Microsoft respectively, do you see the problem if the certificate for one can be used for the other?
Related
I am currently using CloudFlare and recently added an SSL certificate to my script.
Before hand, I added an A record (proxied with CloudFlare) that pointed to my TS IP. It worked like this: ts.domain.net:PORT
However, after I added the SSL cert, it doesn't seem to work anymore.
If it matters, my main site IP is also (of course) proxied under CloudFlare
Thanks!
Every certificate contains one or more Subject Alternative Names. You can use the certificate only on domains that are listed as SAN within the certificate, as long as you don't have a wildcard certificate that can be used on a all subdomain, eg. *.mydomain.net.
Therefore for your TS server you need a certificate that contains the SAN ts.domain.net. If your current certificate is only for domain.net you need another certificate for your Teamspeak subdomain.
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 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.
I am not sure if I need a basic or wildcard certificate and how many.
1) I assume 1 certificate goes in 1 server - so if I have 2 web servers then i need 2 certificates?
2) From what I read wildcard is only needed for subdomains. But what about if i have the same main domain but just use subdomains for multilanguage? like my site is say www.xxx.com and when someone is viewing it in british english i change it to: uk-eng.xxx.com
In the above case will a basic certificate work or is this a wildcard?
Two web servers usually have different host names (if it's not a cluster). So you need protect both host names.
An HTTP certificate protects the host name, so a certificate for "www.xxx.com" is only for this domain. Wildcard allows subdomains, i.e. "*.xxx.com" allows all names e.g. "www.xxx.com" and "uk-eng.xxx.com", but more expencive, however you can use the same certificate on several servers.
One certificate is usually needed per domain, not per server (one cert can cover more than one domain, hence "usually"). For multiple subdomains you would need a wildcard certificate.
If you are not sure, the best idea is to contact CA's support and ask them what they can offer you. Different CAs have different offers for cases like yours.
JFYI: Standard single-domain certificate is usually issued for "domain.com" and "www.domain.com" (so it covers a domain and one of it's subdomains).