Answer the question
In order to leave comments, you need to log in
Why even buy an SSL certificate for a site from GlobalSign/Comodo/etc, if you can sign it yourself?
Don't take it as trolling. I really have this approach to life. The economy must be economical. Each end has its own means.
You can’t bring it to the point of absurdity either, and sometimes you still take it right away with a margin, there is even such an approach - “from one extreme to another” - and for some tasks it is effective in order to immediately assess the prospects.
But you should always understand what you are paying for.
Now, if my goal is just to encrypt traffic to protect against debugging using Wireshark , about no SEO, trust, banking, etc. out of the question, this is an internal server, the client for it will be my own browser (based on WebKit). Or in general the system will work on TCP.
In this case, is a self-signed one enough? Or will a purchased certificate have some real advantages?
And in what case will he have them?
Answer the question
In order to leave comments, you need to log in
Let's take a look at a simple example. you are going to a hotel in another city. and they tell you to give me your passport! why passport? because the one who released it is the guarantor that you are who you are. and the one who asks for a passport trusts the guarantor.
another example. you borrow on parole from a neighbor. neighbor knows you and trusts you. now you act as a guarantor for yourself!
so the question is not in the guarantor. and who trusts whom)
If the certificate is not signed by trusted authorities, then browsers will swear that "the certificate is singed!":
This does not affect encryption in any way. If you use the connection only "himself and my friends", which can be explained that "poke" allow ", and everything will be fine", then you can use self-signed certificates.
If this is a public service, then such messages about an invalid certificate will scare away clients. Then it makes sense to buy a certificate signed by a decent CA.
I wouldn't use Let's encrypt out of principle (actually, I didn't :-) ), even for a home site with cats. A very dubious model when you need to install a certain "client" that generates and renews certificates for you. There is no guarantee that he does not send your secret key to a comrade major over the hill. And then maybe something else, depending on what he can reach.
Not a certificate is bought. A confirmation is bought on behalf of a certain office, which is known to everyone and in which everyone trusts the fact that the certificate holder is in fact the person (organization) that he claims to be. This is actually a big responsibility - sometimes CAs are deprived of trust for jambs - what is the story with a kick in the ass for StartSSL / WOSign Nobody bothers issuing
a certificate to oneself - moreover, this is done very often when no one needs its publicity - for example, a web muzzle iLO, oops, some device for https work generates "at least some" certificate - if you want to change it. Corporate CAs issue certificates to themselves - and they live great.
A purchased certificate provides confirmation of the fact that the person named in the certificate is the one for whom he claims to be. This is guaranteed by the authority of the CA that issues them. You can take a piece of paper and write on it "Pachport of a citizen of all Russia" - but who will believe you?
Trust in different CAs is not unconditional - for some more, for others less - in contrast, for example, to the Federal Migration Service. But the FMS is one, but the SA is many.
In this case, is a self-signed one enough?
this is an internal server, the client for it will be my own browser
Roughly speaking, if there is no need to use this certificate in the public space, then you can use a self-signed one. Otherwise, the question arises of trust in such a certificate among clients (they will have to manually add it to the trusted ones).
These shortcomings are deprived of the certificate from Let's encrypt, which is trusted by all modern software, and its release costs nothing. Receiving and updating is automated.
look at the levels of certificates,
especially at EV (extended validate)
letsenkeript only says that the connection to the site is encrypted
, the levels of certificates also confirm from the reality of the domain owner to the reality of the real office that received the certificate (see Apple, Microsoft, Tinkov)
A green stripe in chrome on your site gives +500 pontoon, compared to other sites))
>encryption of traffic for protection
Self-signed certificates: "encryption of traffic" - Yes , "for protection" - No.
What prevents an attacker from issuing the same fake self-signed certificate and using it for MITM attacks?
Self-signed certificates provide no security at all. If there is any gap on your server and attackers have a reason to try to break it (you can make money on valuable data, etc.), they will simply implement the same self-signed certificate that users will accept without question (because they have already accepted , they don't even think that there might be some kind of danger in it).
In your case, a self-signed certificate is sufficient. Differences from a certificate obtained from one of the trusted certification authorities are only in trust. That is, the OS, browser, and applications do not know anything about the issuer of the certificate and do not trust it by default. If you do not manually tell them that this certificate is trusted, then you will see a certificate error warning.
If you have several such sites, then I would recommend making a small CA and signing certificates for your sites with it. Then browsers should only be trusted by this CA of yours, and not each individual
CA certificate can be made based on any free PKI. There are quite convenient and easy to install and configure.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question