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).
Related
I am trying to connect to localhost over https so that I can use service workers. I have tried many solutions such as chrome flags as described in posts such as this, but none have worked. Finally, I used OpenSSL to make myself a certificate authority and sign my own certificate. However, despite everything running correctly Chrome (and other browsers) still rejected my certificate.
This was due to the lack of subject alternative names. I then added my IP address as an alternate name, but it was not accepted either - chrome told me that the "domain came from [IP address]", along with the error message ERR_CERT_COMMON_NAME_INVALID
What other subject alternative names can I use to prove my identity over localhost? (or alternatively, are there any other solutions?) I am using Apache with XAMPP.
The SAN must match the domain in the URL you use. If you use https://localhost then there must be a SAN of type DNS with value localhost. If you use https://127.0.0.1 then there must be a SAN of type IP with value 127.0.0.1. Not the importance of the correct type and not only of the value.
I use localhost as the common name. From my understanding the SAN must be different but still refer to the same domain ...
No. The CN is actually irrelevant and will usually not even be looked at if a SAN is given (or in case of Chrome: it will never look at the CN and requires always SAN). So just make sure that the SAN is correct.
If I go to www.example.com which has an image on the page that links to assets.example.com which is a CNAME for assets.example2.com.
Will I get the green lock even if assets.example2.com does not have a certificate, but assets.example.com does?
Whether your DNS entry uses a CNAME or an A record doesn't matter. What matters is the host name the client is trying to connect to. It must match one of the Subject Alternative Names in the certificate of the server providing that resource (or, failing that, it must match the CN RDN of the cert's Subject DN).
If https://www.example.com embeds an image to https://assets.example.com (providing both are served over HTTPS with valid certificates for each) and if there is no mixed content (no resource loaded over http://, that is no JavaScript, no image, no iframe, ...) then you should get the green/blue bar as appropriate.
If assets.example.com is a CNAME to assets.example2.com and the requests are made to https://assets.example.com, this machine must present a certificate valid for assets.example.com to the client.
In addition, if multiple certificates need to be used at the same time on this IP address (and same port), support for Server Name Indication (SNI) may be required.
Alternatively, having a single certificate that supports all these names, typically via multiple Subject Alternative Name (SANs) entries, or possibly via wildcard names (which are not recommended), may be used.
This is independent of the DNS resolution mechanism (CNAME or A record).
I am getting the bad certificate error while accessing the server using IP address instead DNS name.
Is this functionality newly introduced in tls1.1. and tls 1.2? It would be good if someone would point out OpenSSL code where it fails and return the bad certificate error.
Why do we get bad certificate error while accessing the server using IP address instead dns name?
It depends on the issuing/validation policies, user agents, and the version of OpenSSL you are using. So to give you a precise answer, we need to know more about your configuration.
Generally speaking, suppose www.example.com has a IP address of www.xxx.yyy.zzz. If you connect via https://www.example.com/..., then the connection should succeed. If you connect using a browser via https://www.xxx.yyy.zzz/... then it should always fail. If you connect using another user agent via https://www.xxx.yyy.zzz/... then it should succeed if the certificate includes www.xxx.yyy.zzz; and fail otherwise.
Issuing/Validation Policies
There are two bodies which dominate issuing/validation policies. They are the CA/Browser Forum, and the Internet Engineering Task Force (IETF).
Browsers, Like Chrome, Firefox and Internet Explorer, follow the CA/B Baseline Requirements (CA/B BR).
Other user agents, like cURL and Wget, follow IETF issuing and validation policies, like RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile and RFC 6125, Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS). The RFCs are more relaxed that CA/B issuing policies.
User Agents
Different user agents have different policies that apply to DNS names. Some want a traditional hostname found in DNS, while others allow IP addresses.
Browsers only allow DNS hostnames in the Subject Alternate Name (SAN). If the hostname is missing from the SAN, then the match will not occur. Putting the server name in the Common Name is a waste of time and energy because browsers require host names in the SAN.
Browsers do not match a public IP address in the SAN. They will sometimes allow a Private IP from RFC 1918, Address Allocation for Private Internets.
Other user agents allow any name in the Subject Alternate Name (SAN). They also will match a name in both the Common Name (CN) and the Subject Alternate Name (SAN). Names include a DNS name like www.example.com, a public IP address, a private IP address like 192.168.10.10 and a local name like localhost and localhost.localdomain.
OpenSSL Version
OpenSSL version 1.0.2 and below did not perform hostname validation. That is, you had to perform the matching yourself. If you did not perform hostname validation yourself, then it appeared the connection always succeeded. Also see Hostname Validation and TLS Client on the OpenSSL wiki.
OpenSSL 1.1.0 and above perform hostname matching. If you switch to 1.1.0, then you should begin experiencing failures if you were not performing hostname matching youself or you were not strictly following issuing policies.
It would be good if someone would point out OpenSSL code where it fails and return the bad certificate error.
The check-ins occurred in early-2015, and they have been available in Master (i.e., 1.1.0-dev) since that time. The code was also available in 1.0.2, but you had to perform special actions. The routines were not available in 1.0.1 or below. Also see Hostname Validation on the OpenSSL wiki. I don't have the Git check-ins because I'm on a Windows machine at the moment.
More information of the rules for names and their locations can be found at How do you sign Certificate Signing Request with your Certification Authority and How to create a self-signed certificate with openssl. There are at least four or six more documents covering them, like how things need to be presented for HTTP Strict Transport Security (HSTS) and Public Key Pinning with Overrides for HTTP.
If I go to www.example.com which has an image on the page that links to assets.example.com which is a CNAME for assets.example2.com.
Will I get the green lock even if assets.example2.com does not have a certificate, but assets.example.com does?
Whether your DNS entry uses a CNAME or an A record doesn't matter. What matters is the host name the client is trying to connect to. It must match one of the Subject Alternative Names in the certificate of the server providing that resource (or, failing that, it must match the CN RDN of the cert's Subject DN).
If https://www.example.com embeds an image to https://assets.example.com (providing both are served over HTTPS with valid certificates for each) and if there is no mixed content (no resource loaded over http://, that is no JavaScript, no image, no iframe, ...) then you should get the green/blue bar as appropriate.
If assets.example.com is a CNAME to assets.example2.com and the requests are made to https://assets.example.com, this machine must present a certificate valid for assets.example.com to the client.
In addition, if multiple certificates need to be used at the same time on this IP address (and same port), support for Server Name Indication (SNI) may be required.
Alternatively, having a single certificate that supports all these names, typically via multiple Subject Alternative Name (SANs) entries, or possibly via wildcard names (which are not recommended), may be used.
This is independent of the DNS resolution mechanism (CNAME or A record).
In a web application, if it doesn't have a domain name (like a web service for example), can you still add a SSL certificate to a IP address?
If yes, how?
You can easily put an ip address into the CN (common name) of an ssl certificate by the same procedure you would use for an ordinary hostname (ssl certificates contain hostnames, not domain names).
How this is done precisely in your case cannot be answered, since you have not stated what your case is.
Browsers should match the CN of a certificate against what the user has put into the URL bar. If it's an ip address, it's an ip address.
This site offers certificates for IP addresses. You wouldn't be able to (properly) use a certificate for a domain name for an IP address, however.
Yes you can, but it isn't common, probably isn't portable, and usually isn't a great idea...Public IP Address
An SSL certificate is typically issued to a Fully Qualified Domain Name (FQDN), but issuers can still offer SSL certificates for a public IP address, typically declared in the CN and SAN values of the certificate, since historically these are referenced varyingly by different flavours/versions of browser. However the facility might only be offered in premium products, eg an 'Organisation Validated' (OV) Certificate covering a whole organisation, or an 'Extended Validation' (EV) Certificate which requires rigorous vetting when acquired.
Private IP Address Space (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8)
In November 2015, the CA/Browser Forum prohibited the use of internal server names and reserved IP addresses in publicly-trusted SSL Certificates. However some issuers do still offer 'Intranet Certificate' services that allow enterprises to continue to issue SSL to internal server names and reserved IP addresses without the need to run their own CA or use self-signed certificates, instead using the issuer's own non-public CAs.
In this scenario it's possible to store internal server names and reserved IP addresses in the CN and SAN values of the certificate. These may also allow options which would otherwise not be permitted under public hierarchies including the use of SHA-1 and 4-5 year certificates etc, furthermore, you can mix internal, FQDNs, sub-domains, wildcard, and public IP addresses in a single certificate under a non-public root.
There's some good information here:
https://www.thawte.com/ssl-digital-certificates/technical-support/browserfaqs.html
I'm almost certain you need a domain to go with the SSL.