If I buy a cert for mycompany.com and I get a valid cert signed by Verisign, What prevents me from generating a fake certificate that is for othercompany.com signed by mycompany?
Doing a man in the middle attack what prevents me from issuing a fake cert for othercompany.com signed by mycompany and include my valid cert as an intermediate CA cert.
One of the "Basic Constraints" that can be attached to a certificate by the issuer is whether or not the certificate is permitted to sign other certificates. These constraints can't be modified without invalidating the certificate. Since a CA will always issue you with a certificate that is marked as an "End Entity" you won't be able to use it to issue other certificates.
Whilst you could likely still create a certificate issued by an "End Entity", any software that correctly validates a certificate chain will mark such a certificate as invalid and reject it.
Related
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs. On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
I know the truststore is to verify the 3rd party certificate during handshake
My question is what should my truststore actually store during handshake?
Youtube.pem (the CA signed certificate sent from 3rd part)
Google.crt (the CA certificate)
According to TLS connection definition, for example, as the client-side, I use keystore to store my private key and certificate, and use truststore to store some kinds of certs.
Yes, but you only need a keystore if you want to use client side authentication. Note that "keystore" and "truststore" indicate how the store is used, they can be of the same type (e.g. PKCS#12) and even the same file.
On the server-side, that call it Youtube, it has a root certificate called Youtube.pem which is signed by Google.crt CA.
No, YouTube is a service, it has a leaf or end-entity certificate. The root certificate is that of a third party CA. The end-entity certificate is usually signed by an intermediate CA certificate, and that is in turn signed by a self signed root certificate.
I know the truststore is to verify the 3rd party certificate during handshake
It is used to validate and verify the trust path from leaf certificate to a trust anchor in your truststore. The trust anchor is usually one of the root certificates stored in your truststore. The leaf certificate is indicated by the end entity / server, the intermediate certificates are usually sent by the server as well, but they could also be retrieved from a cache.
In the case of YouTube, the Google root CA is used, possibly using the GlobalSign root through a linked certificate if the Google root is not present in the trust store.
So your truststore should either contain the Google root certificate or the GlobalSign root for the connection to work in this example.
Why does self signed SSL certs throw an unsafe warning? They actually have a smaller attack profile, and not as easily cracked like commercial ssl from a CA. So in reality, a third party cert is more unsafe than a self signed one. Even the wiki page says this: https://en.wikipedia.org/wiki/Self-signed_certificate
A self-signed certificate does not create a security warning if it is configured as trusted in the browser. If it is not known as trusted yet the browser has no way to find out who issued the certificate: it can be the original certificate from the target server or it can be a certificate created by man-in-the-middle attacker. And that's why it is throwing a security warning.
With a CA signed certificate instead the browser can forward the trust it has in the CA (i.e. it is in the local trust store) to the certificates issued by this CA. This means does not need any more to trust every new certificate explicitly up-front but it is enough to trust the specific CA which signed the certificate. This makes the process of rolling out certificates much simpler.
Of course, the risk of the CA model is that one might put too much trust into a CA. The problem of the self-signed model is that you have to find a way to distribute the certificate before connecting to a site in a secure way to the browser - which means that you somehow need to trust this secure distribution of the certificate and that you will run into the same or even worse problems with this than you have in the CA model.
Self-signed carts throw an unsafe warning because your computer does not trust your CA, but (instructions different depending on the environment) you can set your computer to trust your CA.
In accordance with Microsoft a minimum key length for a certificate should be of 1024 bits since August 2012. I have created a self-signed certificate having a key length of 4096 bits. But the certificate information shows the following error:
When I inspected the public key length it shows the following screen:
But instead of having "This certificate is OK." as a status, I am getting the following error:
How can I resolve this issue?
Thanks...
Where do you see a self-signed certificate? Self-signed certificate is the certificate where Subject and Issuer fields are the same. In your case, it is not self-signed.
I can suspect, that the certificate was either, not signed by InfoValley Inc., or signature algorithm is not recognized on your system. Can you tell us the following information:
Authority Key Identifier extension value from leaf certificate
Signature algorithm used to sign leaf certificate (2nd and 3rd fields)
Subject Key Identifier extension value from InfoValley Inc. certificate
I'll explain at least one other way that you can get an invalid digital signature that happened to me. I have a set of scripts that build may certificates and a set of scripts that installs certificates in the windows certificate store. The script that installs the certificates first deletes the certificates that I'm going to install and then installs the new certificates. I thought the script was working just fine, but it turns out I had little bug in the script. I have one Trusted Root CA certificate that is used to sign my Intermediary Trusted Root CA certificates. The problem was that I chose the wrong "certificatestorename" for the trusted root certificate. So, instead actually deleting my trusted root certificate before I installed it, I ended up creating a second trusted root ca certificate in the Trusted Root Certificate Authorities store with the same distinguished name. And that's what cause my 2nd level intermediary CA certificates to report that they had an invalid digital signature.
What made this problem a little difficult to spot was that if I looked at installed 2nd level intermediary CA certificates after being install in the windows certificate store, those 2nd level intermediary CA certificates all showed that the "This certificate is "OK" and no issues with the certificate chain. The problem caused by the two trusted root certificates with the same distinguished name didn't exhibit any problems until I tried to validate a certificate that was signed by one of my 2nd level intermediary CA certificates. It's when I look at those certificates that I saw my 2nd level intermediary CA certificates all had an invalid digital signature.
So, this is at least one way that I observed that you can get this error message. Technically speaking, the error means that the issuer of the certificate cannot validate the signature of the given certificate, which is not the same thing as not finding the issuer certificate in the trusted store. Others have reported that this problem can occur in windows if you generate a certificate whose key length is 512.
I have bundled a pfx certificate within an application for a user, however now it appears that the certificate has been expired.
Is there anyway for me to renew the certificate on my side (server) without distributing the renewed certificate to the user ?
No, it would seriously undermine the whole idea of trust in certificates for things that should stay secure.
If you check your certificates with openssl verfify be sure to also add -verbose and -issuer_check
Remember that for a certificate to be valid, all certificates in the chain (up to the Root CA) need to be valid and in the trusted CA store and not on a revocation list.
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.