I have a .keystore file and Tomcat's configuration is: keystore=.keystore and truststore=.keystore
The .keystore contains a PrivateKeyEntry (signed by CA1) and a trustedCertEntry (CA1).
Everythink ok so far.
If the trustedCertEntry would not be present when importing server certificate, I would get: Failed to establish chain from reply
When I delete the trustedCertEntry (CA1), Tomcat can not start because of: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Now my question: When I delete trustedCertEntry CA1 and import a trustedCertEntry CA2, Tomcat starts and the certificate chain (view in browser) is: The server certificate which is signed by CA1.
How can this be possible? I would have expected that Tomcat can not start since the trustedCertEntry (CA2) does not match with the PrivateKeyEntry since PrivateKeyEntry was issued from CA1 and not CA2. And since Tomcat can not start without a trustedCertEntry.
Private key is not issued by CA.
Your server certificate is a pair of public and private key. Based on this key pair certificate request was created and this certificate request was signed by CA1. Certificate is valid in your browser as long as CA1 is in trusted CA in certificate store of your browser.
Changing CA in keystore doesn't affect server certificate.
It looks like at least one CA cert is requirement of SSL engine - I'm guessing that any CA cert (i.e. thawte.com/roots, or self-signed) imported to JKS will work for you - JKS must have at least one.
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'm trying to create web application with client certificates, generated programmatically. My main problem is following: I've added generated .p12 keystore to my web browser, but it doesn't send certificate to the server.
How does browser understand which x509 certificate it should use? And is it possible to debug SSL in Chrome of Firefox?
SSL/TLS server sends Certificate Request message (see RFC 4346 for TLS 1.1 or others). In this message there is only certificate type and acceptable certificate authorities names, so server doesn't tell anything about particular certificate.
The possible reason is that your certificate of invalid type (i.e. DSA instead of RSA but key exchange algorithm depends on client RSA certificate), or server requests certificate of different certificate authority.
I have created a CA using OpenSSL. Now i want my server to send Certificate Signing Request(CSR) to CA and receive the signed certificate.
My question is, Is there any specific method provided by OpenSSL to transfer the CSR and signed certificate between the CA and server? Or i should just send the CSR to CA using any method (e.g. my own client-server program that sends CSR and receives signed certificate) and receive the signed certificate in same way.
Hope I have clearly stated my question. Waiting for response.
Regards
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.