I am trying to set my tomcat with SSL. I have finished it. But, when I surf on my server the SSL certificate is not trusted.
I imported into my .keystore file a Certificate of one entity, but the result is the same.
This is what i want:
This is what i got
Can you help me?
If you only want a certificate that is accepted by browsers and clients "automatically", without adding an anchor to the truststore, you must get a certificate issued by one of the established Certificate Authorities that is builtin to the browser(s) and/or other client program(s) you use. (Note the CA portion of Verisign is now owned by and operates under the name of Symtanec, which also owns Thawte and Geotrust but they still operate under their prior names.)
No trusted CA will issue you a cert for the name "localhost", only for a publicly resolvable and reachable domain name that you own, so if you don't have a domain name you'll have to get that first. Some suppliers, like GoDaddy, do both DNS and certificates (and other things like hosting); you may or may not prefer a single supplier. (Or you may be able get a cert for a static public address, but that's harder to get and harder for people to use.)
If you want the green bar in browsers, that requires Extended Validation which costs more, typically USD 300 and up, and you must prove your legal identity and status by government records. To do this in practice you must be a business, registered and licensed as appropriate for your location.
Related
I have a server and a few clients, all running on different docker containers. The users can use the client by entering localhost:3000 on their browser (where the client docker is running).
All the containers run on the same LAN. I want to use HTTPS.
Can I sign a public private key pair using my own CA, then load the CA's public key to the browser?
I want to use the normal flow for public domains, but internally with my own CA.
Or should I look for another solution?
Meta: since you've now disclosed nodejs, that makes it at least borderline for topicality.
In general, the way PKIX (as used in SSL/TLS including HTTPS) works is that the server must have a privatekey and matching certificate; this is the same whether you use a public CA or your own (as you desire). The server should also have any intermediate or 'chain' cert(s) needed to verify its cert; a public CA will always need such chain cert(s) because CABforum rules (codifying common best practice) prohibits issuing 'subscriber' (EE) certs directly from a root, while your own CA is up to you -- you can choose to use intermediate(s) or not, although as I say it is considered best practice to use them and keep the root privatekey 'offline' -- in cryptography, that means not on any system that communicates with anybody, such as in this case servers that request certificates, thus eliminating one avenue of attack -- on a specialized device that is 'airgapped' (not connected or even able to be connected to any network) and in a locked vault, possibly with 'tamper protection', a polite name for self-destruct. As a known example of the rigor needed to secure something as sensitive as the root key of an important CA, compare Stuxnet.
The client(s) does not need and should not be configured with the server cert unless you want to do pinning; it(they) do need the CA root cert. Most clients, and particularly browsers, already have many/most/all public CA root certs builtin, so using a cert from such a CA does not require any action on the client(s); OTOH using your own CA requires adding your CA cert to the client(s). Chrome on Windows uses the Microsoft-supplied (Windows) store; you can add to this explicitly (using the GUI dialog, or the certutil program or powershell), although in domain-managed environments (e.g. businesses) it is also popular to 'push' a CA cert (or certs) using GPO. Firefox uses its own truststore, which you must add to explicitly.
In nodejs you configure the privatekey, server cert, and if needed chain cert(s), as documented
PS: note you generally should, and for Chrome (and new Edge, which is actually Chromium) must, have the SubjectAlternativeName (SAN) extension in the server cert specify its domain name(s), or optionally IP address(es), NOT (or not only) the CommonName (CN) attribute as you will find in many outdated and/or incompetent instructions and tutorials on the Web. OpenSSL commandline makes it easy to do CommonName but not quite so easy to do SAN; there are many Qs on several Stacks about this. Any public CA after about 2010 does SAN automatically.
I just installed a Cloudflare Origin CA ssl certificate on my server. Because I have many domains on this server, I configured the certificate to protect them all, so I can use only one certificate for all my domains (domain1.com, domain2.com, etc...).
I went to check my ssl was working properly with the service whynopadlock.com, and I realized this service can list ALL of my domain names on the server by just accessing domain1.com? Are all the domains in a certificate meant to be public, is this normal behavior and can I avoid it?
I also noticed whynopadlock.com lists some domains in the certificate that are not mine. Does it mean Cloudflare is using the same certificate for many different users?
Are all the domains in a certificate meant to be public, is this normal behavior and can I avoid it?
All certificate subject alternate names are part of the certificate and are sent to every client that tries to connect securely.
There is no way to avoid it unless you want to use separate certificates for each domain.
I also noticed whynopadlock.com lists some domains in the certificate that are not mine.
Cloudflare states that this is normal:
Are Cloudflare SSL certificates shared?
Universal SSL certificates are shared across multiple domains for
multiple customers. If certificate sharing is a concern, Cloudflare
recommends a Dedicated or Custom SSL certificate.
Note that Cloudflare (as of Feb 2019) does provide dedicated certificates if you do not want to use a shared certificate.
Can I use a certificate from letsencrypt to sign local certificates?
I'm annoyed when accessing routers and APs at 192.168.x.x to get security warnings.
I could create my own root cert, and import it into all my browsers etc, and create certs for all the local servers.
But I'd rather have the chain device -> www.example.com -> letsencrypt -> root
Then also guests could use my local servers/services without this security error.
No, you can not because the certificate issued to you by letsencrypt will not have the keyusage certificate signing enabled. Without this attribute in the issuer, any browser or SSL client musth reject the certificate.
If this were possible, anyone could issue valid certificates for any server simply by having a valid certificate from a trusted CA
If you want to issue certificates for your local servers you will need to create your own CA and include the root certificate in the truststore of each client
Yes, you can... but not like that
Yes, you can get certificates for servers on a private network. The domain must be a real domain with public txt records, but the A, AAAA, and CNAME records can be private/non-routable (or in a private zone).
No, the way to do that isn't by using Let's Encrypt certificates to sign local certificates.
You can accomplish exactly what you want to accomplish using the DNS-01 challenge (setting txt records for your domain).
Who is your domain / dns provider?
Immediate, but Temporary Solution
If you want to test it out real quick, try https://greenlock.domains and choose DNS instead of HTTP for the "how do you want to do this" step.
Automatable Integration
If you want a configurable, automatable, deployable solution try greenlock.js (there are node plugins for Cloudflare, Route 53, Digital Ocean, and a few other DNS providers).
Both use Let's Encrypt under the hood. Certbot can also be used for either case and can use python plugins.
Possibly related...
P.S. You might also be interested in a service like Telebit, localtunnel, or ngrok.
I work with a web application used by several business units in my organization. The application is accessed using a general URL http://app/ but some of the units use a business friendly URL e.g. http://bu1/, http://bu2/ etc.
The application is soon to be integrated with a portal that requires it to be configured to use SSL and I was advised to request a certificate using a fully qualified domain name so I went with app.company.com. The certificate has been installed on the server and users access it using https://app.company.com/.
However I would also like them to be able to use https://app/ or https://bu1/ or http://bu1/ etc. I'm not clear on how to do this, I think I have the following options:
Should I have requested a certificate without using the fully qualified domain name, just the CNAME?
I keep coming across subject alternative names but they appear to relate to different domains and I'd rather the users didn't need to use a domain at all. 3. Shoud I be looking for a wildcard certificate instead? I think one of the posts on here says they are not recommended.
Do I need a certificate per domain?
Many thanks for any advice!
SSL certificate providers will not hand out a certificate unless it lists a fully qualified domain name that you own through a registrar, so you will not be able to get a signed certificate for https://app/ for instance.
What you need to do in this case, if you really want users to be able to access your app through https://app/, is to create your own self-signed SSL certificate, then insert the certificate into the browser's trusted certificate list on every computer in the company.
For this use case you should set up a certification authority inside your company and issue certificates for the internal domains using your own CA. You'll have to make sure that the computers inside your company trust your root CA certificate automatically.
Also, you can't buy SSL certificates for an internal domain name/reserved IP address anymore.
From the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0 (emphasis is mine):
9.2.1 Subject Alternative Name Extension
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully-Qualified Domain Name or an iPAddress containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate.
Wildcard FQDNs are permitted.
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name. Address or Internal Server Name.
I have configured an Apache httpd website with SSL client side certificates so that only users who have installed the correct certificate in their web browsers can access the website.
If there is only one client side certificate installed the web browser will automatically select it (it is not the default, but it can be configured somewhere in the settings dialog). But if a user has more than one certificate installed, the web browser presents a list of certificates and the user has to pick the right one to continue.
The question is: Is there a way to configure httpd to send a hint so that the web browser can automatically select the required certificate?
The SSL (TLS) protocol only allows the server to specify two constraints on the client certificate:
The type of certificate (RSA, DSA, etc.)
The trusted certificate authorities (CAs) that signed the client certificate
You can use "openssl s_client" to see which CAs your Apache server trusts for client certs. I do not know how to configure Apache to change that list (sorry), but I bet there is a way. So if you can limit the list to (say) your own organization's CA alone, then you will have done all you can to allow a Web browser to select the client cert automatically.
As Eugene said, whether the browser actually does so is up to the particular browser.
I'd say that as selection of the certificate is a client-side task, there's no definite way to force the client use this or that certificate from the server side.
In addition to what #Nemo and #Eugene said, by default, Apache Httpd will send the list of CAs it gets from its SSLCACertificateFile or SSLCACertificatePath configuration directives.
However, you can force it to send a different list in certificate_authorities using the SSLCADNRequestFile or SSLCADNRequestPath directives and pointing them to another set of certificates. Only the Subject DN of these certificates is used (and send in the list). If you want to force certain names, you can even self-sign these certificates with whichever name you want. I've tried this (in conjunction with SSLVerifyClient optional_no_ca, and you can get clients to send certificates for CA certificates that the server doesn't actually have. (This isn't necessarily useful, but it works.)