Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What's means of Self-Signed Certificate in OpenSSL

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.)

like image 234
Sam Avatar asked Apr 28 '12 07:04

Sam


People also ask

What is the meaning of self-signed certificate?

Definition(s):A public-key certificate whose digital signature may be verified by the public key contained within the certificate. The signature on a self-signed certificate protects the integrity of the information within the certificate but does not guarantee the authenticity of that information.

What is difference between self-signed certificate and SSL certificate?

While Self-Signed certificates do offer encryption, they offer no authentication and that's going to be a problem with the browsers. Trusted CA Signed SSL Certificates, on the other hand, do offer authentication and that, in turn, allows them to avoid those pesky browser warnings and work as an SSL Certificate should.

Why is self-signed certificate needed?

By choosing this type of SSL certificate, you are effectively on your own. This means you don't have the backing of a trusted certificate authority and application of the latest cryptographic methods necessary to ensure proper authentication and encryption of data, devices, and applications.


2 Answers

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.)

like image 143
Bruno Avatar answered Oct 26 '22 23:10

Bruno


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.

like image 27
robrich Avatar answered Oct 26 '22 22:10

robrich