This may be a trivial question but a friend asked me this the other day and I couldn't explain it properly.
So, as far as I know, a TSL certificate contains (among others) the name of the subject and some information used to generate the public key.
The subject would be a domain name like www.example.com
Of course, the name of the domain(s) must be included so that only the certificate for example.com and be used on example.com and not the certificate of another domain (certificate swapping).
But (!) it is somehow anchored in my brain that the certificate also identifies the owner (person) in some fashion and proves that the domain is owned by an identified human.
Is this not the case? Is the purpose of a TLS certificate really just mapping public-key-information to a domain name?
Thanks.
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 have registered domain on one server and pointed to justhost server space. I have purchased ssl certificate from thirdparty. Where I have to add the certificate I got , on domain server or justhost server which I have uploaded files?
It's hard to understand your setup but where the certificate lives is ultimately not relevant. What really matters is what is in the Common Name (CN) field of the certificate and/or what is in the Subject Alternative Names (SAN) extension. And the rule is simple: if the user enters https://example.com/this/that/whatever to get to your site then your certificate must contain example.com in the CN component of the subject and/or the SAN extension.
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 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.
The common name for my SSL Key is .mydomain.com . What common name should i get issued so that i can use a URL like https://api.mydomain.com and https://api-test.mydomain.com ?
You can create a wildcard certificate using *.mydomain.com
Somehow wildcard ssl and simple domain ssl both are same. For your SSL key concern, the only change you should is common name. Wildcard ssl requires key for *.yourdomain.tld.
PS: All SSL CA requires 2048 bit CSR key.
Here you check how it makes difference and similar.
Technical Difference:
Simple ssl and wildcard ssl carry different common name. As explained above.
Simple SSL secures only www and non-www domain name. Where wildcard secures unlimited sub-domain names.
Similar terms:
Both requires domain control verification process. DCV process is compulsory for everyone to acquire ssl certificate.
Both support same technology ssl encryption.
Both requires 2048-bit CSR key.