I would like to have an SSL cert for *. That is, for any domain whatsoever. The idea is to sign it with a custom CA cert, install that CA cert on a target device, and use that device to connect to ip-based addresses (e.g. https://192.168.1.123). There's no DNS available, and the address may be different each time. The browser on the target device should work without warnings, but only as long as the wildcard cert presented is signed by the known CA (which is our custom CA the cert of which was installed on the device), to prevent any possible MITM attacks.
Would browsers understand such a wildcard cert? Is there any other workaround possible to allow using browsers to connect to arbitrary IP-based SSL servers without warning and with MITM protection at the same time (assuming that it's possible to customize the client list of CAs)?
There are two specifications about certificate identity validations for HTTPS: RFC 2818 (the HTTPS specification itself) Section 3.1 and RFC 6125 (a more recent RFC trying to harmonise how this is done for any protocol).
As far as I can interpret RFC 2818, it doesn't forbid it (although I guess it doesn't consider the use case at all):
Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f.com matches foo.com but not bar.com.
RFC 6125 generally discourages the use of wildcard certificate altogether (section 7.2) and only allows it in principle in the left-most label (section 6.4.3). This more or less implies that there should be more than one label.
There is an additional errata for RFC 6125 on the subject: "RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier":
Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".
Specifications aside, this is unlikely to work in practice. No commercial CA should ever issue one of those. They make mistakes once in a while perhaps, but hopefully nothing so foolish. You might be able to achieve this by deploying your own CA (or perhaps with a local automated CA within a MITM proxy you'd approve). Even if this was the case, some clients will simply refuse to validate such certificates. For example, Chromium even forbids *.com or *.co.uk.
Note that in both cases, wildcards are for DNS names, not IP addresses. Having a certificate for * as you would like wouldn't work for your use-case anyway. Perhaps looking into alternative DNS solutions (e.g. mDNS) to be able to use a name might help.
Yes there are wild card certs. You may please check with SSL cert provider to get more details .I doubt if this can be based on IP
While the public key infrastructure is broken, it is not that broken that you will get an certificate for * and the browser will accept it. The relevant RFC is RFC2818 and if you read it you'll see that the browser accept *.example.com and www*.example.com, but not www.*.example.com, www.*.com or even *.
Related
I have a need to add system trust for a local CA certificate. This is prompted by a couple of applications but notably curl which warns about untrusted certs when connecting to our CA signed HTTPS endpoints.
I have seen a rainbow of answers on this question with some very ambiguous and vague explanations:
/etc/pki/ca-trust/source/anchors/
This appears to be the most common answer and is described as being "high priority" but there is no explanation to what that means. I can make two guesses, both terrible: one, these are loaded first before the rest but what value does that have? Does any application really interrupt the OS loading of certs stores and have a chance of not getting the 'lower priority' CAs? Two, that there's some swordplay of the blacklisting and whitelisting between the stores. E.g. The blacklist here overrides whitelisting elsewhere, or whitelisting here overrides blacklisting elsewhere. This seems so dangerous as to be unlikely.
/usr/share/pki/ca-trust-source/anchors/
This is "lower priority" than 1 but when should I use this? Always? Never? Does it even matter?
/etc/pki/ca-trust/source/
This is the same as 1 but in a "BEGIN TRUSTED file format"? Presumably this some kind of legacy format but no documentation to that effect. (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-shared-system-certificates_security-hardening)
/usr/share/pki/ca-trust-source/
Again, same as 2 but "BEGIN TRUSTED file format".
/etc/ssl/certs/ca-bundle.crt
No clue.
/etc/ssl/certs/ca-bundle.trust.crt
Even less clue.
/etc/pki/tls/certs/ca-bundle.crt
Sure, why not. (https://access.redhat.com/solutions/1549003)
/etc/pki/tls/certs/ca-bundle.trust.crt
Yep. (Also https://access.redhat.com/solutions/1549003)
/usr/share/pki/ca-trust-source/ca-bundle.trust.crt
It keeps going....
/usr/share/ssl/certs/ca-bundle.crt
Fedora Core 2 only?
Some other SO questions to 'clarify' the issue:
How to add Certificate Authority file in CentOS 7
https://serverfault.com/questions/739980/importing-ca-certificate-chain-crt-rhel7
https://serverfault.com/questions/394815/how-to-update-curl-ca-bundle-on-redhat
https://serverfault.com/questions/1025749/how-to-remove-a-root-ca-certificate
I am using Firefox 59.0.1 on Ubuntu and I am seeing the following error when accessing my development environment which is behind a self-signed SSL cert.
Your connection is not secure
The owner of crmpicco.dev has configured their website improperly. To
protect your information from being stolen, Firefox has not connected
to this website.
This site uses HTTP Strict Transport Security (HSTS) to specify that
Firefox may only connect to it securely. As a result, it is not
possible to add an exception for this certificate.
Learn more…
Report errors like this to help Mozilla identify and block malicious
sites
crmpicco.dev uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: SEC_ERROR_UNKNOWN_ISSUER
I have added "crmpicco.dev" to security.tls.insecure_fallback_hosts and set security.enterprise_roots.enabled to true, restarted Firefox but this has had no effect.
I know Chrome has their "badidea"/"thisisnotsafe" workaround, which I know isn't ideal but it at least works - whereas I am yet to find a Firefox equivalent.
What is the solution for this? Do I need to generate new self-signed certs even although the cert I have is from Feb 2018.
I have tried the numerous questions on here and Mozilla support to no effect.
The top level domain *.dev is owned by Google. For some time already there has been a pre-configured HSTS policy in Chrome which made it impossible to use self-signed certificates for this domain. Firefox recently added such policy too so you get the same behavior now.
There are several ways to deal with this. The best way is to not use any currently public or future public top level domains for your private purpose. By using such domains you risk to getting in conflict with usage policies enforced by the domain owner, like enforcing HSTS in case of *.dev. Also, it might even cause security problems. Instead use either domains you actually own or use top level domains which are reserved for internal and test use, like *.test, *.invalid or *.example.
If you really want to use *.dev internally (again, bad idea) you can do it by following the policy of this domain: don't use a self-signed certificate but use a certificate issued by a CA trusted by your browser. This means creating your own CA, adding it as trusted to the browser and then issue the certificates you want by this CA. But again, using public domains you don't own (no matter if top-level or not) is a receipt for trouble.
I am trying to set up a NGINX to perform client authentication against multiple clients. The problem I have is that those clients will have different certificates, basically different Root CAs:
[clientA.crt] ClientA > IntermediateA > RootA
[clientB.crt] ClientB > IntermediateB1 > IntermediateB2 > RootB
I looked at the NGINX documentation and I noticed the ssl_client_certificate directive. However, that property alone seems not work by itself, for example, if I configure it for only work for clientA for now:
ssl_client_certificate /etc/nginx/ssl/clientA.crt;
ssl_verify_client on;
Then I received a 400 error code back. By looking at other questions, I figured out that I also have to also use ssl_verify_depth: 3. Therefore, if I want concatenate both clientA and clientB in a bundle PEM to allow both clients, will I need use a high value? What's the purpose of this directive and what are the implications of setting to a high number with a bundled PEM?
The http://nginx.org/r/ssl_client_certificate directive is used to specify which certificates you trust for client-based authentication. Note that the whole list is basically sent every time a connection is attempted (use ssl_trusted_certificate as per the docs if that's not desired).
As per above, note that ssl_verify_depth basically controls how easy would it be to get into your system — if you set it at a high-enough value, and someone is able to obtain a certificate with one of the CAs that you trust, or through one of their intermediaries which they trust to generate their own certificates, then they'd be able to authenticate with your nginx, whether or not that's your desire.
As such, it'd normally be the practice that all certificates that are used for client-based authentication are generated by a privately sanctioned CA, hence, normally, there shouldn't be much of a length to the chain. If you want to equalise the depth number between the two CAs, to get the best protection from ssl_verify_depth, then it's conceivable to create an extra CA to add to the depth, then that CA to the trusted list instead of what's now an actual intermediary. (Note that it gets complicated once you involve a few intermediaries, the browser would need to know of their existence, which is usually cached, and can result in a number of ghost issues when non-cached.)
Also, note that you don't actually have to have a single CA in the specified file — it can include multiple unrelated "root" CAs, so, if you want to add multiple independent CAs, you don't actually have to bother creating another CA to certify them — you can just include such independent CAs as-is.
be sure that you use 2 different root certificates with actually different DN, if you are trying this locally with certificates which have the same DN this will not work, as stated by nginx here
https://trac.nginx.org/nginx/ticket/1871#ticket
We were stuck with this long when I found this old issue also in kubernetes.
https://github.com/kubernetes/ingress-nginx/issues/4234
My Apache https server has returned the following header as a response for a request to https://lab20.example.com:
Public-Key-Pins:pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains
Those pins are for purpose invalid - but still google chrome 52 allows to connect to my labs. It looks like HPKP is not working. I have also tested:
chrome://net-internals/#hsts - and after querying lab20.example.com indeed i see HSTS (confirmed working fine) but not HPKP - i do not see any dynamic_spki_hashes. Why ?
Do i need to activate something in chrome in order to be able to understand and process HPKP headers ?
Thanks,
The header will ONLY be accepted if it's valid and then used for future visits (within the max-age time).
This is specified in the spec:
The UA MUST note the Pins for a Host if and only if
...snip...
o The TLS connection was authenticated with a certificate chain
containing at least one of the SPKI structures indicated by at
least one of the given SPKI Fingerprints (see Section 2.6).
This is to stop you accidentally bricking your site and is a GREAT feature to reduce dangers of accidental badly implemented HPKP.
It does however make testing bad HPKP quite difficult. Either manually add the headers using that internals page you cited, get two different certs for your page, or set a valid header at top level (with includesubdomains) and use a different cert for subdomain to test.
OK, found out a reason, i have used my enterprise CA, but:
Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.
I need to see how a web application will work with HTTPS. But I can't really find much information around about it. I tried to set up my local Apache but I can't find a CA autorithy to sign my certificate... Hints? Suggestions?
The possibilities to consider are:
Generate your own certificate (self-signed certificate)
Get a certificate issued by a known issuer
Get a certificate issued by an issuer not recognised by the browser
Nr. 1 is probably the most widely used solution. You can find instructions here. The only disadvantage is that browsers will complaint about the unknown CA. In Firefox, you can just add a permanent exception and get rid of the warning. (Neither Chrome nor Internet Explorer seem to provide such option.)
Nr. 2 normally costs money so it isn't a popular choice for dev environments.
Nr. 3 can be obtained for free (see https://www.cacert.org/) but they also trigger a browser warning. A difference with nr. 1 is that you have the possibility of adding the CA to your browser's trusted authorities; however, that's a serious decision that requires serious consideration because of its security implications. In general, I would not recommend it for mere testing.
Self-signed certificates (as already mentioned) are probably the easiest option for a single host.
If there are a few hosts, you could create a mini CA of your own. There are tools for this, for example:
CA.pl: a script provided with OpenSSL.
TinyCA: a tool with a GUI.