I am setting up a Health Check in Oracle Cloud Infrastructure for DNS failover. The destiation is only reachable through HTTPS and has a valid SSL-Certificate for the domain name. However, when activating the health check, it always fails with error message:
x509: cannot validate certificate for x.x.x.x because it doesn't contain any IP SANs
I tried to set the domain name in the HTTP header host field. However, this does not seem to help in the SSL authentication.
Is there a way to ignore SSL errors for the health check? Or do I somehow need to include all IP addresses in the SSL certificate? I would like to avoid having to get a new signed SSL certificate each time an IP address changes or is added.
Related
I am trying to connect to a service over HTTPS, and currently the connection fails due to certificate mismatch with the hostname. I am receiving different certificate host name depending on whether I connect using hostname or IP address. The hostname does resolve to exact same IP address, but it consistently keeps giving different certificate for the IP address when using curl. Using python requests module, it always gives me the certificate I get with curl and IP address (which is unfortunately the wrong one).
Any explanations what might be going on here?
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/
My web server's FQDN is foo.bar.com
It is aliased and most commonly accessed at baz.bar.com
I had a SSL certificate generated by our netsec guys and I installed it to the server and enabled the site. Now I am receiving Error code: SSL_ERROR_BAD_CERT_DOMAIN because the certificate is only for foo.bar.com, not baz.bar.com
How can I get this resolved?
The hostname in the URL you use to access a site must match a subject of the certificate. This means if you want to access the site as bot baz.bar.com and foo.bar.com you either need a certificate which contains both or need two certificates and serve the certificate based on the request name. In the last case the client must support SNI if both names point to the same IP address.
I have a IIS 7 server hosting a few different sites. Recently I purchased and installed a SSL certificate to one of the site. Both http and https binding are setup with host header xxx.com and www.xxx.com.
But now i discover that other site with no SSL is loading the certificate and show the untrusted cert error when accessing through https.
Can i know how I can stop other non SSL site from loading the certificate?
Thank you.
I assume that
you are using the server on a single IP address
provide service for multiple names on this single IP address
have configured SSL for some of the names but not for others
This means, that
The server is listening on this specific IP address for SSL connections.
The server can only decide after receiving the initial SSL request from the client (ClientHello) which certificate it should use. The Client hash to use SNI (server name indication) to tell the server which hostname it expects. Most newer clients support this but for example IE8/XP does not.
Since the server has to listen for SSL connections on this IP address it can happen, that it receives a SSL request for a hostname, where it has not certificate configured. In this cases a server could do the following:
Use some other certificate it has configured. This is what your server is doing. This results in an error on the client about an invalid certificate since the name in the certificate does not match the expected name.
Simply close the connection or issue some SSL error. This would result in an SSL handshake error on the client which browsers usually display in a way so that end users are not able to understand what's going on. For the browser the situation is simply a server error and the server is not able to give the browser more detailed information (this is not part of the SSL protocol).
If you don't like any of these two problems you must serve the non-SSL hosts from a different IP address than the SSL hosts, so that the server will not even listen on the SSL port for connections for the non-SSL hosts.
I hope this explanation helps with your problem. If you have now specific questions about the configuration of the server to achieve the outlined solution you should ask them at serverfault.com instead.
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.