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
Related
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 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 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.
A PCI Compliance scanner is balking that the self signed SSL certificate protecting secure access to Plesk Panel contains a name mismatch between the location of the Plesk Panel and the name on the certificate, namely the self-signed cert's name is "Parallels" and the domain to reach Plesk is 'ip address:8443'.
So I figured I would go ahead and get a free SSL certificate to try to fiddle with this error. But when I generated the certificate I used my server domain name as the site name when I generated the certificate. So if I visit 'domain name:8443' all is fine, no ssl warning. But if I visit 'ip address:8443' (which I believe is what the scanner does) I get the certificate name mismatch error, Digicert's ssl checker says that the certificate name should be the ip address.
Can I even generate a certificate whose common name is the ip address? I am tempted to say I should just do what the PCI scanner accepts, but what is really the correct common name to use? Anybody run into this issue before?
You can try a Subject Alternative Name extension for the IP address. Also, you can keep "Parallels" as the Common Name, and add a Subject Alternative Name extension for the DNS name, which should be the preferred match (i.e. higher precedence than Common Name.)
Can I even generate a certificate whose common name is the ip address?
No, you shouldn't. While this may work with some browser, this will fail with clients that are compliant with the HTTPS specification:
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
If you want to use an IP address in a certificate, you must have it in as a Subject Alternative Name (of type IP address, not DNS). You can check this question for details on how to do this.
However, more importantly, it sounds like in your case you don't need to use the IP address at all.
The purpose of certificate name verification is to check that the identity in the certificate matches the identity as requested by the client. (Reverse lookups or other names don't matter.)
The fact that you've already configured your system for your domain name and that it works when using the name means that it's already configured properly. It sounds like your giving your scanning tool the IP address of what you're trying to scan (which isn't what the clients would normally use): make it use your host name instead. That's what the scanning tool should try to compare anyway.
Can I even generate a certificate whose common name is the ip address?
(Thanks Bruno for pointing to right solution) There is enough to set subjectAltName in CSR.
IFAIK there is no such option in Plesk, but here good instruction for openssl http://apetec.com/support/GenerateSAN-CSR.htm
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.)