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.
Related
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.
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.
I'm completing an assignment on SSL and I feel I understand the basics of how certs are used with asymmetric and symmetric encryption. But I'm having difficulty understanding some details of how exactly trust hierarchies work.
Specifically, what is used to sign an intermediate certificate? All the guides I've looked at state that the CA root cert is used to sign the intermediate cert. But what exactly does "sign" mean here? In other words, how does a server prove that its intermediate certificate is authenticated by the CA root cert?
My guess is that the public key or signature of the root cert are used when generating the signature of intermediate cert the but I'm not sure if this is accurate.
I would really appreciate any info to improve my understanding.
If there is exactly one intermediate, which is often but not always the case, the intermediate cert is signed by the root in exactly the same way an end-entity cert (for SSL/TLS mostly a server cert) is signed by the intermediate. In both cases this is a shorthand; signing is actually done using the private key of an asymmetric keypair, and the cert contains the public key of the same keypair which is used to verify signatures made with the private key. Since the private keys are private and all of us who use the CAs see only their public keys, we focus on that. Thus:
the server cert is signed using the private key belonging to the intermediate CA; the intermediate cert contains the matching public key. As part of verifying the server cert, the relier (e.g. browser) finds or confirms the intermediate cert using the Isssuer name in the server cert, and uses the public key from the intermediate cert to verify the signature on the server cert; this assures that the server cert was actually issued by the intermediate CA and has not been tampered with.
According to SSL/TLS standards the server should always send the intermediate cert (or certs, in order) following the server cert in the handshake, although if it fails to do so, some clients may use AIA from the certificate or other heuristic means to obtain the cert, or may have it already cached or even configured.
the intermediate cert is signed using the private key belonging to the root CA; the root cert contains the matching public key. As part of verifying the intermediate cert, the relier finds the root cert using the Issuer name in the intermediate cert, and uses the public key from the root cert to verify the signature on the intermediate cert; this assures that the intermediate cert was actually issued by the root CA and has not been tampered with.
The root cert normally must (already) be in the relier's local 'trust store' and the server does not need to send it; normally the trust store is provided either by the browser developer (Firefox) or by the OS/platform developer (IE/Edge, Chrome, Safari).
Notice the close parallel between these two statements with the (notable) exception of how the relier finds the parent cert. Also note that validating a server cert chain for an SSL/TLS connection involves much more than just verifying the signatures, although verifying the signatures is a critical part and without it the other validation criteria could not be assured.
One intermediate CA, and intermediate cert, will generally be used by a large number (thousands to millions) of server certs and servers. The server isn't responsible for 'proving' anything about the intermediate cert, only passing it on to the client, which validates the entire chain.
Cross-stack see also
https://security.stackexchange.com/questions/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity
which has a nice graphic of this relationship.
A certificate authority is supposed to verify a website is truly who they say they are, right. But certificate authorities sign there own certificates. So those certs are self signed. Is there a way I can find out if the self signed certificates they use on their website is reputable and trustable?
You have to trust the CA who issued the certificate. Otherwise, we encounter the classic chicken-egg problem where there is no concrete boundary for trust and certainty.
Once you trust the CA issuer, you can check whether the certificate you have was actually issued by the concerned CA by writing the following on a command line:
$ openssl verify -verbose -CAfile cacert.pem server.crt
Expected Output: server.crt: OK
If you get any other message, the certificate was not issued by that CA.
Visit https://kb.wisc.edu/middleware/page.php?id=4543 for more info
No, you just trust them! The most common way is to follow the herd... for example, extracting them from the browsers (http://curl.haxx.se/docs/caextract.html). We are always assuming the browsers are verifying it for us... as well as the operating systems...
Is there a way [you] can find out if the self signed certificates they use
on their website is reputable and trustable?
You can research the certificate authority yourself.
Some people may not trust a certificate authority, including Google. Google posted a list of authorities they did not trust back in May of 2016:
https://www.theregister.co.uk/2016/03/23/google_now_publishing_a_list_of_cas_it_doesnt_trust/
You either have to trust that the pre-installed certificates that came with your tools (web browser, etc) are trusted by the producers of those tools, or you can do some research and see if you really trust them yourself. It's basically like asking how you can trust anyone or anything. Can I trust you?
I trust the CA's that come installed with my browser because well, if I can't trust them then we all have a problem and that problem is bigger than me. I think it's good to ask questions like this and I wonder if anyone other than Google are questioning certificate authorities.
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.