I have generate .p12 file from my server. But righ now we are developing IOS app which requires CA to implement it.
We are using Amazon EC load balancer server, so i have not idea where I can get CA, also is it possible that .p12 can generate CA?
A CA is a Certificate Authority. It is an organization that generates a public/private key pair for you. A PKCS#12 is a standard that explains how to store public/private key pairs in a file. Your .p12 file is such a file. It is a keystore that contains digital certificates (a public and a private key pair) as defined in PKCS#12.
If you have a .p12, there are two options:
Either your certificates are self-signed. In this case, you have created your own public and private key pair and you've stored it inside a .p12 file. As no CA is involved, there is no way to check if you created those certificates, or if somebody else impersonating you created those certificates.
Or you obtained that .p12 file from a CA. In this case, the CA signed your certificate and there is a certificate chain that eventually leads to the root certificate of your CA. A CA doesn't hand out such certificate to just anybody. A CA will first check that you are who you say you are. This way, whichever party gets confronted with your certificate (for instance because you used your private key to sign your code), knows that you are who you say you are, provided that your CA is a trusted party (there are CAs and then there are CAs).
This image shows how it works:
You are Bob, Apple is Alice, Trent is your CA. Apple wants you to work with a CA because Apple doesn't know you, but Apple knows CA. Once you make yourself known to the CA and once the CA trusts you, Apple will trust you.
See https://en.wikipedia.org/wiki/Alice_and_Bob to find out how the names in this image were chosen.
So the real question is: can you extract your public key from your .p12 file and show it to us so that we can see if your certificate is self-signed or if it's signed by a CA? Without that info, I don't think anyone can help you.
Related
How to introduce one level of certificate chain while signing a jar file? What I am trying to do is,
Sign a jar with generated private key.
Generate a CSR (Certificate Signing Request)
Generate a CA signed certificate where CA is self sign CA
import CA in jcontrol and browser and run the java web start application.
but unfortunately it didn't work and gave security warning.
Please suggest some good approach.
TLDR: get the cert first
Java codesigning uses the PKCS7/CMS signature format, wbich is based on X.509/PKIX public-key certificates. The sequence you posted uses the privatekey as it if magically appeared, but that is impossible. I'm going to bet your sequence actually was:
0. keytool -genkeypair
Although the name focusses attention on 'generate keypair', this single command actually does three things: generate a keypair; create a dummy, self-signed certificate for the public half of that keypair; and store both the private half of the keypair and the dummy certificate together in a keystore (usually a file). Note the java.security.KeyStore API does not support storing a privatekey -- or a publickey or raw keypair -- by itself, only a privatekey combined with a certificate chain. (The dummy cert, by itself, constitutes a trivial chain.) For concreteness I will call this dummy cert A.
1. Sign a jar with generated private key = jarsigner
You specify to jarsigner a privatekey entry in a keystore, but as above that entry actually contains the cert chain as well, in this case the dummy cert. The PKCS7/CMS signature contains a raw PKC signature (RSA, DSA, or ECDSA) computed using the privatekey, plus the cert which matches that privatekey and thus can be used to verify the signature, plus any chain cert(s) needed to validate the signing certificate. You can see this if you look at the contents of the META-INF/<alias>.{RSA,DSA,EC} entry in the resulting jar.
2. Generate a CSR (Certificate Signing Request) = keytool -certreq
3. Generate a CA signed certificate where CA is self sign CA
How you did this depends on your CA, but doesn't matter here. To be exact, a CA may have a self-signed cert for the public half of the CA keypair, but as above it actually signs certs it issues using the private half. For concreteness I will call the cert issued by the CA for the signing key B, and the CA's own self-signed cert C.
4. import CA in jcontrol and browser and run the java web start application.
I'm not sure if you mean B or C here. But neither will help in verifying the signature done in step 1, because that signature contains and specifies A as the 'signer' cert, i.e. the cert to be used to verify the signature. B is a cert fort for the same publickey, and could be used to verify the signature if the signature specified cert B, but it doesn't, and can't because B didn't even exist when the signature was created.
The correct sequence is:
-genkeypair
-certreq
use CSR to get cert B from CA. You don't actually need C here, although you might get it for convenicnce or reference.
-importcert cert B into the privatekey entry. (If you defaulted the -genkeypair alias to mykey you can default -importcert also, otherwise you must specify the same one.) This replaces the dummy cert A with the 'real' cert B in the privatekey entry. (Be careful not to import cert B to a different alias, or different keystore; this often doesn't give an error. but the result won't work correctly.)
If the 'real' cert B needs one or more chain cert(s) to validate, as is (always?) true for certs from real public CAs like Digicert, GoDaddy, LetsEncrypt, etc, such chain cert(s) must be either included in step 4 (as a combined file, often a 'p7b' or 'p7c' file), or separately imported prior to step 4 into a separate trustedcert entry or entries. However, your in-house CA does not need any chain cert(s).
now jarsigner -- so the signature includes cert B (and its chain certs if any)
A. separately, cert C must be included in the truststore(s) used by the client system(s); this can be done anytime: after, during or before steps 1-5. For webstart, I believe putting it in Java Control Panel should be sufficient; AFAIK webstart isn't validated by the browser. Applets may have been, but applets haven't worked in browsers for several years or in Oracle Java higher than 8.
I'm trying to fix an issue related to an expired ca certificate.
I replaced a the certificate located at /etc/puppetlabs/puppet/ssl/ca/ca_crt.pem (with these instructions).
Then restarted puppet-server, but agents still see an expired certificate.
I noticed there is also a value localcacert which points to a slightly different path etc/puppetlabs/puppet/ssl/certs/ca.pem.
I see this little snippet on Puppet documentation:
Where each client stores the CA certificate.
Default: $certdir/ca.pem
I'm confused by this. The description makes it sound like a folder where clients store certificates, yet the value is a single pem file.
Can anyone clarify the difference between these two ca pem files?
If I update one can I just overwrite the other with my new pem?
Can anyone clarify the difference between these two ca pem files?
The cacert setting is relevant only to the master. It specifies the location of the certificate with which the master's hosted CA will sign communications.
The localcacert setting specifies the location of the client's copy of the CA certificate (containing the public key, not the private one). This is what machines will use to verify certificates signed by the CA.
In both cases, you should not read too much into the word "location". These settings designate certificate files, not directories.
Can anybody clarify to me what kind of "Private Key" is located in a PFX file ?
I am asking this because after having read quite a lot on digital certification I am still a bit confuse on the Private Key part, especially when Certificate Authority is involved.
The part I am missing is where it is said that the Private Key is kept secret on the CA side but if I go in my Personal Certificate Store and I try to export a certificate, I am able to export it with the private key in it.
Is this private key is the same as THE private key that we are not supposed to know ?
Public key cryptography is used for two different purposes when it comes to X.509 certificates used for SSL/TLS.
Each X.509 certificate contains a public key, which has a matching private key held only by the identity this certificate belongs to (the subject of the certificate).
One of the purposes is to build trust in another certificate. A CA uses its private key to sign other certificates: possibly other (intermediate) CA certificates or End-Entity Certificates (the ones that are actually going to be used for the SSL/TLS connection itself).
For example, the Root CA's private key can be used to sign (i.e. issue) an Intermediate CA's certificate. The Intermediate CA certificate can be verified using the Root CA certificate's public key. The Intermediate CA's own key-pair isn't involved in this verification (although the verification process ensures that the public key in that cert belongs to the Intermediate CA).
The Intermediate CA's private key can be used to sign your server certificate (an EEC). The Intermediate CA's public key can be used to verify the authenticity of your server certificate. Someone who would only have the Root CA certificate can therefore check your server certificate by building a chain. Again, your server public and private keys are not involved in this verification at all, but the result of these operations proves that the public key in your server certificate belongs to your server name.
There is no relationship between any of the key pairs involved in a certification chain. Even the CA issuing a certificate will not (or should not) have access to the private key of the certificate it is issuing.
The second usage of public key cryptography is during the SSL/TLS handshake. The exact mechanism depends on the cipher suite, but this allows the client to agree with the server on a secret that only the server with the private key matching the public key in the server certificate will be able to see. It's this private key that is the private key of the certificate itself.
In a PKCS#12 file, you will find an End-Entity Certificate and the private key matching the public key in that certificate, to be used by the entity to which this certificate was issued, and generally a chain of CA certificates (from the one directly issuing the EEC to other CA certificate further up the chain, possibly up to a Root CA).
Here, I've taken this example of an EEC for an SSL/TLS server, but the same could apply for EEC to be used in other contexts (e.g SSL/TLS client or S/MIME).
If you are talking about SSL-Certificates and SSL I think you mean X509-Certificates in common. Let me make it clear first: the passwords of the private keys are different.
The magic here is Chaining of the Certificates, i.e.
Root Certificate from CA
Intermediate Certificate from CA (for instance Class 2)
Your Certificate
If you look at your SSL-Certificate, you will find this structure. Every certificate within this hierarchy can be seen as a certificate for its own. You can find more information within this msdn article. A briefly description from my point of view:
The Certifcates within this chain can be seen are separate Certificates. With their own ability to sign Information with the private key and validating signature with their private key. They are basically linked within this chain.
You might ask Why are the Certificates linked?
There are two main reasons: Security and Trust.
If you loose your private key or if your certificates is broken, it's need to be revocated. This basically says, that your Certificates should not be trusted anymore. It's listed on the Revocation-List on the parent Certificate to ensure that this security break can be fixed very fast. This behavior explains, why root certficates creating IntermediateCertificates and not your requested Certificate - they want to be sure that they can revocate their Intermediate Certificate as well.
Additionally to this functional explanation there is a mathematical, but I am not able to explain this is an easy way. You can find Information about this within it's article on Wikipedia. Basically it says, that you can't calculate the password from the parent and / or public certificate to use the private certificate.
I'm a beginner in OpenSSL tools. I don't understand some concepts. Can you explain these concepts to me?
I want to understand concepts such as CA,Self-Signed Certificate or any concept for better understanding.
(Sorry if I am using the wrong terminology or grammar, I am learning english language.)
The purpose of certificates is to assert a piece of information in a way that you can verify. Public key certificates, more specifically X.509 certificates in this context, assert the binding between a public key, identifiers (the Subject Distinguished Name and/or Subject Alternative Names) and various other attributes. Altogether, these pieces of informations are signed so as to form the certificate.
X.509 certificates have both an issuer and a subject. The subject is the identifier representing who or what that certificate identifies (and who or what owns the private key matching the public key within this certificate). The issuer represents the identifier of the person or organisation that what used their private key to sign this certificate.
Certificate usage can be broadly split into two different categories: certificates that are used for a specific application or service (e.g. authenticating an SSL/TLS server), and certificates that are used to prove the validity of other certificates.
For the latter, certificates are used as building blocks of Public Key Infrastructures (PKIs). A Certification Authority (CA) is an institution that issues certificates: it signs the assertion that binds the public key in the certificate to the subject. When doing so, it puts its own name as the issuer name in the certificate it issues.
If you compare a certificate to a passport (which binds together your picture and your name), the CA would be your passport authority: those who actually certify that what the passport says is true, for others to be able to verify it.
Trusting a CA allows you to trust the certificates it has issued. You can build a chain of trust between a CA you trust and certificates issued by this CAs which you haven't seen before.
Along with this comes a "bootstrapping" problem: how do you trust the CAs themselves?
Self-signed certificates are certificates where the issuer and the subject are identical; they are signed with the private key matching the public key they contain. They are at the top of the chain of trust. They tend to be CA certificates (unless bespoke for a particular service, which you wouldn't be able to trust without external verification).
CA certificates are certificates that can be used for issuing/validating other certificates. (They can be intermediate CA certificates if they are in the middle of the chain between a root/self-signed CA certificate and a certificate you wish to verify.) The rules defining how certificates can be used to verify other certificates are defined in the PKIX specification (RFC 3280/5280).
Browsers and operating systems come with a pre-installed list of CA certificates that you trust by default. These are mostly commercial CAs which check the information about the service in the certificate, often for a fee. In counterpart, you can trust the content of the certificates they issue (most of the time, it's not a perfect system). There is a "leap of faith" involved here, since you need to trust the browser/OS to have included only reputable CA certificates.
If you use openssl s_client and you see a message like "self-signed certificate in the chain" or "unable to verify certificate", it doesn't necessarily mean that something is wrong, but openssl doesn't use a pre-defined list of trusted CA certificates by default. Most of its command have an options like -CAfile or CApath that allow you to specify which CA certificates you are willing to trust.
Self-signed certificates for a service are a specific case, whereby the service self-asserted its content. You generally have no way of verifying the authenticity of such a certificate, unless you have an external way of trusting it (for example, if you have installed it yourself on a machine and change check its content manually, or if someone you trust gave it to you).
(You may also be interested in this question about how an HTTPS server certificate is used.)
Generally the purpose of a certificate is to establish a trust chain: "I trust this 3rd party company, they trust you, therefore I can trust you." Self-signed certificate means you generated it yourself, and therefore I'm really not gaining trust in you. (These are great for testing, but not much else.) The other type is a trusted certificate, obtained by getting a reputable company to sell you one (like Verisign). It's a commodity market, so their prices are pretty consistent between companies. It does depend on the intended use and the scope of the certificate. (e.g. a certificate for signing an Android app is very different from a certificate used for validating https://www.example.com/.)
The "CA" or Certificate Authority is the company that issued the certificate. In the case of a trusted certificate, it's that company -- e.g. Verisign. In the case of a self-signed certificate, the CA is you -- you issued the certificate.
Self-signed certificates will cause some kind of "untrusted" alert in most browsers, asking you if you want to proceed and add an exception, etc. This does not mean the connection is any less secure though -- it is still over SSL.
Generally CA's charge a fee but there are some free ones around if you search.
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.