I need to setup https for multiple domians xxxx.com xxxx.net (with single common certificate)
CA where we buying certificate ask to create Certificate Signing Request (CSR), but when I'm generating it with openssl - it asks only for one name
how to make one CSR for multiple domains ?
Avoid certificates with multiple CNs (as suggested in comments), that's not how the specifications (RFC 2818 and RFC 6125) say it should work and, although it may work in some clients applications, it will usually fail. From RFC 2818:
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
Instead, generate certificates (or CSR) with multiple Subject Alternative Names (SANs).
If you're using OpenSSL, edit your openssl.cnf (or edit a copy) and set these properties, in the relevant sections ([req] and [ v3_req ]):
[req]
req_extensions = v3_req
[v3_req]
subjectAltName=DNS:www.example1.com,DNS:www.example2.com,DNS:www.example3.com
There's also a nice trick to use an environment variable for this (rather in than fixing it in a configuration file) here: http://www.crsr.net/Notes/SSL.html
You may also want to have one of them (any) in the CN.
(You may also be interested in this answer.)
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 am trying to implement Mutual Authentication in Kubernetes, I am able to create the certificate and able to configure it into the cluster too, But I am getting error when I send certificate from client side.
So here is the problem
When I create the certificate I have to give Common Name. This field must contain a fully qualified domain name.
Since my domain name is very long 93 characters, it is not allowing me to enter my domain name,
My doubt is, is it mandatory to have full domain Name in Common Name field while generating the certificate, or do we have any workaround for this.
TIA
You can provide the Fully Qualified Domain Named(FQDN) in Subject Alternative Name instead of Common Name. Subject Alternative Name don't have the limitation of 64 characters.
The general rule is that the domain is checked against all SANs and the common name. If the domain is found there, then the certificate is ok for connection.
RFC 5280, section 4.1.2.6 says "The subject name MAY be carried in the subject field and/or the subjectAltName extension". This means that the domain name must be checked against both SubjectAltName extension and Subject property (namely it's common name parameter) of the certificate. These two places complement each other, and not duplicate it. And SubjectAltName is a proper place to put additional names, such as www.domain.com or www2.domain.com
As per RFC 6125, published in '2011 the validator must check SAN first, and if SAN exists, then CN should not be checked. Note, that the RFC 6125 is relatively recent and there still exist certificates and CAs that issue certificates, which include the "main" domain name in CN and alternative domain names in SAN. I.e. by excluding CN from validation if SAN is present, you can deny some otherwise valid certificate
I have one server Certificate installed on apache server that have following feilds
1) Common Name : 192.168.0.107
2) Subject Alternative Name :
IP:192.168.0.108,IP:192.168.0.109
When browser access any of the subject alternative name then browser shows green padlock ( secure connection) but when i try to access server by its common name browser shows (insecure connection). why this is happening is there any fault in my certificate? please help me out with this
Note : I have installed root certificate on browser
Since HTTP over TLS was introduced in 2000 an defined by RFC2818 the use of the commonName field has been considered deprecated and if SubjectAlternativeName is present, it must be used.
If a subjectAltName extension of type dNSName is present, that MUSTbe used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
Most browsers require currently the SAN extension and do not even accept certificates with only CN. See https://security.stackexchange.com/questions/172626/chrome-requires-san-names-in-certificate-when-will-other-browsers-ie-follow
We're using HAProxy (v1.6.9) to verify client certificates(X.509 v3) and do SSL termination. We want to validate the Extended key usage and the basic constraints extensions in the client certificate. By looking at the HAProxy source code and OpenSSL verify documentation, I guess the keyUsage extension would be validated. But, does it do validation of the Extended Key Usage as well as Basic constraints extensions? If not, then is there a way to set this information in the request header and forward it to the application, so that the application can validate it?
Based on my understanding of OpenSSL documentation, we need to set the "purpose" option in verify to validate these extensions and I couldn't find this option being set in HAProxy's source code. Please correct me, if I'm wrong.
Thank you.
When you use commandline verify or call X509_verify_cert you do need to specify 'purpose' if you want it checked, because these operations can handle cert chains used for any purpose (or combination of purposes). For SSL/TLS protocols this is handled automatically, because the libssl code knows that it received and is checking a cert/chain for an 'SSL' (including TLS) server or client; see function ssl_validate_cert_chain in ssl/ssl_cert.c -- this line has the effect of specifying 'purpose'. For release 1.1.0 only (so far) the purpose is also checked against optional local trust attributes for the anchor/root (in addition to ExtendedKeyUsage extension(s)).
The statement on the man page that "If the -purpose option is not included then no checks [of untrusted cert extensions] are done." may be misleading. If purpose is not specified no checks for purpose are done, but some checks of extensions are always done regardless of purpose -- at least always for a proper chain with CA cert(s) distinct from the EE cert; for a selfsigned EE cert, which acts as its own anchor and effectively its own CA, some checks are inapplicable.
In particular, as mentioned a few paragraphs earlier, during the build phase CA (aka issuer) certs are checked for KeyUsage.certSign and SKI/issuer/serial matching AKI. During the second phase all untrusted certs are checked for BasicConstraints (and the now-rare NetscapeCertType) and KeyUsage.certSign (again), and NameConstraints (since 1.0.0), and the EE SAN or Subject is matched if a peer id was configured (which generally makes sense only if the peer is the server, hence not your case, and only since 1.0.2); also revocation checking (which may involve extensions) if configured (not the default); and if purpose checking is configured (which it is for libssl) in addition to ExtKeyUsage on all untrusted certs it checks KeyUsage and NetscapeCertType of the EE cert. Although the EE KeyUsage check here is not specific to the ciphersuite and thus keyexchange method negotiated; that is checked separately in libssl.
And the final phase in addition to checking signatures and validityperiod (as stated) also checks the RFC3779 extensions if used (almost never?) and if configured (probably rare) CertificatePolicies plus PolicyMappings, PolicyConstraints, and InhibitAnyPolicy.
Do note extension checks only fail if the extension is present with an inconsistent value; if an extension is omitted (by the CA) from a given cert it effectively permits everything related to that extension.
HTH.
We have a wildcard .pfx file that's of the pkcs 12 convention. We have a vendor that's trying to use it, but it's only working on the whatever.company.com sites (for desktops), and not working on the m.whatever.company.com sites (for mobile). We're assuming this is happening because the wildcard cert is only for *.company.com, and not *.*.company.com.
Do we need to get a new cert created for *.*.company.com or does anyone know of a way to... I don't know... append the additional sub-subdomain to the existing cert? Maybe with keytool and/or OpenSSL .... ?
First, you cannot edit an existing signed certificate without invalidating the signature. And with an invalid signature the certificate will be considered invalid and rejected by the browser. Just imagine if editing a certificate would be possible and the edited certificate accepted by the browser: in this case an attacker could easily modify an existing certificate for its own domain to include any other domain for which he wants to do a man in the middle attack.
Apart from that wildcards like *.*.example.com are not possible, i.e. only a single wildcard is allowed and only in the leftmost label.