I obtained a SSL certificate from my company's certificate authority. The Common Name value of the certificate contains a repeated domain name like so:
host.domain.domain
It should actually be:
host.domain
Not sure how this happened. Will this pose a problem when a browser tries to verify the certificate?
Related
I don't understand what value does an SSL certificate have to assure the users the website belongs to the entity written in the certificate.
Anyone can buy a domain and fill the certificate the way he wants, the Certificate Authority doesn't check the id of the owner of the domain and compare it to what he fills in the certificate.
And then the certificate will show false information to users visiting the site.
I don't understand what value does an SSL certificate have to assure the users the website is valid.
It does not have such a value. A certificate does not make any statements about a website being "valid" (whatever this is in the first place) or "secure" or similar statements about the content or the owner of a website. A certificate only ensures that the website reached is the domain shown in the URL. This way it protects against man in the middle attacks on the communication.
... the Certificate Authority doesn't check the id of the owner of the domain and compare it to what he fills in the certificate
For domain validation (DV) certificates no domain owner is even shown in the certificate, but only the domain name. And it is checked by the CA that the one asking for the certificate has actually control over the domain. Extended validation (EV) certificates contain owner information - which are also verified by the CA.
Does a non-self-signed certificate, imported into root store, require a (self-signed) issuer to also be imported into the root store?
Suppose I've a certificate A that is signed by another certificate B. Is it then sufficient to only import A into the root store, i.e. certificate validation stops at A, or should B also be imported into the root store for proper certificate validation?
The reason I'm asking this question, is that I've encountered different results with different products (e.g. web browser or system), and so I want to know the right way.
You should include Cert B in truststore. As mentioned in the comments, your mileage may vary as clients, as well as servers, implement RFC differently.
In terms of rules, spec for x.509 certs is in IETF RFC 5280. The key information is that for SSL handshake to happen client should do a full cert chain validation, which ends up with a self-signed certificate that is in your trust store.
Your Cert is not self-signed, it is issued by a different CA (cert B). If you do not have B in your truststore, then trust chain is broken. However, again as mentioned above, it is possible that client will not validate the full cert chain.
Think of it this way. Your client is presented with Cert A, which is signed by "B". Client should verify that signature on A is fine, which means it needs (certificate of) "B". If B is a "root" CA or self-signed, its "issuer" and "subject" fields will match. And if that Cert B is in your TrustStore, you are golden.
It's the job of the server to send you a certificate list for TLS.
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it.
There is a visual representation of certificate chain verification here. Hope it helps.
When I try to upload an SSL certificate for my Bluemix custom domain, I receive this error message:
BXNUI2072E: The intended host name, *.<custom_domain>, is not a subject within the certificate.
How can I go about getting my certificate uploaded successfully and avoid this error?
Thanks!
I learned that the problem here was due to the certificate I was using, which was for a single, specific domain. Bluemix supports only wildcard certificates, that's a key point.
I got around this by replacing my single domain certificate with a wildcard certificate.
To generate a wildcard certificate, I needed to specify a wildcard domain by adding an asterisk (*) and a period (.) in front of my custom domain name.
In the example that follows I used OpenSSL to generate a self-signed wildcard certificate. I've generalized the example but simply specify a wildcard domain for the Common Name field.
Common Name (e.g. server FQDN or YOUR name) []:*.<custom_domain>
I tested and succesfully got this to work for both a self-signed certificate and a certificate signed by a certificate authority.
I guess it can't be done, but if so, I'd like to know why.
Let's say I get an SSL certificate for example.com from one of the official certificate authorities around. Let's also say I'm running a.example.com and b.c.d.example.com and would like to have SSL certificates for those as well.
Can I use the example.com certificate to issue certificates for a.example.com and b.c.d.example.com myself? And will they be recognized by users' browsers? If not, why not?
(My guess that it can't be done is because it would break the very lucrative wildcard cert business model, wouldn't it?)
Clarification: can't I act as a "self-signed" certificate authority using the keypair for which I obtained the official cert, and simply add my official cert in the validation chain?
You cannot use Your certificate to issue other certificates, because the purposes of the
certificate are encoded in Your certificate and "Certificate Authority" is certainly not included in that list.
Web browsers check the "certificate chain" beginning from Your certificate, the certificate that was used to sign it, the signer of that certificate etc.
Your certificate must match the current use case (mostly "identify web site") and all signing certificates must include the "Certificate Authority" flag. The last certificate must be known to the browser (root cert).
As You already guess, wildcard certificates might help in Your case.
You're correct, you cannot issue certificates from a certificate. You need a Certificate Authority to issue certificates.
The whole point of a Certificate Authority is that they are a trusted 3rd party. CA's like Verisign are trusted by default by most browsers so that you dont have to manually accept certificates from them. They have what is termed a trusted root certificate.
If you create your own Certificate Authority and start dishing out certificates, web browsers will not know you and hance not trust you. The user will be prompted.
We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.