Came across a packet capture where the client hello SNI had this value *.immedia-semi.com. Is having a wildcard in the SNI valid?
The server_name extension (SNI) is intended to specify a hostname. From RFC 6066:
"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client.
Given that a wildcard is not a valid FQDN it is not valid here either. Similar IP addresses are not FQDN too and are even explicitly forbidden here.
Client TLS implementations usually don't check what is given by the program as SNI too use and thus sometimes broken SNI are seen in the wild, caused by application bugs.
Related
The SSL/TLS certificates used to secure websites allow for specifying a subdomain wildcard:
*.example.com will be valid for www.example.com, subdomain.example.com etc.
Is it possible to use wildcards for IP-addresses? In particular, I want an SSL-certificate for local development like this:
192.168.1.*, which would then be valid for any of the 256 different IP-addresses that are reachable inside the NAT-network of my WiFi router.
Instead of just using localhost, 127.0.0.1, 0.0.0.0, ::1 as alternate names for my certificate, I also want to be able to connect my mobile phone to test the development version of my website which would be available at lets say 192.168.1.40. But then the same certificate could not be reused from a different development machine - since it would get a different IP on the same network.
Let's encrypt doesn't support using IP-addresses - which means I would instead use self-signed or locally trusted certificates instead.
No. RFC 2818 section 3.1 specifies wildcard matching for dNSName items; although it isn't clear here, this is universally implemented to allow the wildcard only as the leftmost DNS label, which is the least significant because DNS names are right-to-left. It specifies that if iPAddress is used the match must be exact (no wildcard), and even if it allowed wildcard, because IP addresses are left-to-right, only a wildcard at the right, like the one you proposed, would be useful.
However, if you're only using a /24 of 192.168.x.0 or less, as many people do, and likely only some of the addresses in that range, it's not hard to just list all the addresses you need in the cert. For example, if you're using DHCP-assigned addresses, often those cover only half or less of the range nominally available from the netmask.
No CA operating under CA/Browser forum rules, and thus acceptable to major browsers, will issue a cert for a private (RFC 1918) address; see the Baseline Requirements at https://wwww.cabforum.org . They won't do local or 'fake' domainnames like .local .localdomain .dev .test either, for the same reason.
BTW 127.0.0.1 and ::1 are real addresses, albeit not routable and thus usable only locally. 0.0.0.0 and ::0 are different; they aren't addresses at all, and you can't connect() to them; in fact they are used to represent the state of not being connected. You can use them in bind() but that actually means bind to all configured addresses (and interfaces).
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/
DNS traffic (requests and responses) has been encrypted by DNSCrypt. In this case, is hostname (https://www.example.com /destination IP adress) readable in transit by a third party during my TLS session? Actually i would like to clarify what does make hostname visible to others - unencrypted DNS traffic only or both unencrypted DNS and initial request to the destination server in the TLS session context?
The hostname is part of the Server Name Indication (SNI) extension of the TLS handshake. When this extension is used it is send in clear inside the ClientHello part of the handshake. All current browsers use SNI.
Apart from that the hostname is usually part of the servers certificate. The certificate is also send in clear by the server during the SSL handshake.
Which means DNSCrypt only protects the DNS lookup and nothing more.
BTW, a better forum for such kind of questions is security.stackexchange.com.
I have a requirement to host address-bound or domain-bound certificates in either DNS CERT records or LDAP servers that are discoverable by other parties.
I tried to search on internet about them but didn't got much information.
So basically I need some link or some little explanation about address-bound or domain-bound certificates.
Thanks.
X.509 certificates when used for authentication of servers during SSL/TLS handshake include the server's host name or IP address in Subject.CommonName field and/or in the corresponding field SubjectAlternativeName extension. This information restricts the use of the certificate to certain host and also identifies the host. When the client connects to host A using IP address 1 and receives the certificate issued for host B and/or IP address 2, this is an evidence of either misconfigured server or fake server or stolen certificate. In these cases security of the communication can not be guaranteed.
What you are asking for are not standard terms, that's why you can't find information about them. The certificate can have both host name (or several) and IP address (or several) in it, so the certificate can't be called strictly "something-bound".
I'm implementing mutual SSL between service A and service B. Service A uses both 1-way and 2-way SSL. 1-way for the communication between a user and website A, and 2-way SSL to forward requests from that user to the service B in a secure way.
1-way SSL in service A is specified in Tomcat server.xml. 2-way SSL is implemented using JSEE secure socket communication on the client side (service A), and Tomcat config (service B). Atm. when I try to access service A I get ssl_error_rx_record_too_long error.
According to this answer ssl_error_rx_record_too_long and Apache SSL one of the reasons may be the fact that I'm using more than one SSL certificate for the same IP. Is this really the case that you can't use the same IP for several certificates? Even if one certificate is a server certificate (for 1-way SSL) and another is a client certificate (for 2-way SSL)?
This may not be the cause of my problem, but I just want to make sure if it's actually possible to have several certificates for the same FQDN. Thanks for help!
ssl_error_rx_record_too_long generally has nothing to do with certificate configuration, but the fact that what's talking on that port isn't actually using SSL/TLS.
The answers (and even the update to the question) in the question you linked to also point to this problem (e.g. missing SSLEngine on). You probably forgot something like SSLEnabled="true" in your connector configuration.
As I was saying in an answer to your other question, being able to configure two server certificates on the same IP address isn't really a problem for your case.
it's actually possible to have several certificates for the same FQDN
It is possible to configure multiple certificates on the same IP address and port using the Server Name Indication TLS extension, but both servers and clients would need to support it. In particular, this is not supported by the JSSE in Java 7 on the server side (only on the client side), but there are workarounds if you're willing to put a reverse proxy in front of your Java server.
This wouldn't be possible to do this with the same FQDN, since it's what allows to pick the certificate. This being said, having multiple server certificates for the same FQDN on the same IP address is generally pointless. Supporting multiple certificates is precisely useful when you need to support distinct names.