Is a certificate chain valid if its certificates have different keysizes i.e. a user certificate has keysize pair of 2048 bits and its CA certificate ahs keysize of 1024 bits or vice-versa.
Thanks.
Of course it is valid. The validation is only about if the user certificate has been signed by the CA certificate (and if the CA certificate have the proper extensions configured - not all libraries check this though).
The keysize is unrelated to the validation of the chain
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.
The certificate's subject name and issuer name are different but the certificate authority used to create the certificate has the same issuer and name.
Therefore since the certificate authority is self-signed, are the certificates it creates also considered self-signed?
No. Self-issued means that the Issuer and Subject are the same and self-signed means a self-issued certificate whose contained public key can verify its own signature. (Some software and most humans ignore the signature check and just treat all self-issued as self-signed.)
Note that all root authorities are self-signed, because the PKI trust system has to start somewhere.
I have a self signed CA which has 1024 bit key length. Is it possible to sign a server certificate with longer key length (2048 bit) using this CA? I want to sign a server certificate and configure that for Active Directory service.
I'm able to do this using bouncy castle. My concern is about
1) Is this a good idea?
2) How would the certificate trust be established? Would that be okay.
Yes, you can use your 1024-bit RSA private key to sign a certificate for a server that is using a 2048-bit key. The length, and even the type, of the key in the certificate you're signing (the server's certificate) has no relation to the key you're using to do the signing. For example, you could have your 1024-bit RSA private key sign a certificate for a server using a 256-bit EC key if you wanted.
(Technically, you aren't signing the certificate itself, but a hash of the certificate. See this question and answer for details. But conceptually, you can think of it as "signing the certificate".)
Trust is established the same as with any other certificate chain:
Your client contains your CA's 1024-bit public key in its trust store.
Your client connects to a server, which sends its certificate, signed by your CA.
Your client sees that the certificate is signed by a CA in your trust store, so it verifies the CA's signature on the server's certificate using the CA's public key in the client's trust store.
The signature matches, so the client trusts the server's certificate.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I'm not clear on the difference between a CA key and a certificate. Isn't a CA key simply a certificate? Let me try and clarify with an example.
I have a client and a server. I'm only trying to validate my connection to my server and not trying to establish trust to others so I don't care about signing with a real CA.
Option 1: Generate a self-signed CA (ssCA) and use that to sign a certificate (C). I then install ssCA into the root keystore on my client and setup my server to use certificate C.
Option 2: Generate a self-signed certificate (SSC). Install SSC into the root keystore on my client. Setup my server to use certificate SSC.
The second option seems like a much simpler process. Should that still work?
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
You can openssl x509 -noout -text -in $YOUR_CERT to see the differences between files contents:
In your self-signed CA, you can seeļ¼
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
And in your self-signed certificate, it's:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.