You don't seem to understand the issue with self-signed certificates, so allow me to explain.
Generally, when people say "Don't use self-signed certificates!", they mean in the context of a web-server, in which you expect the general public to connect via a web browser. In such a situation, if a self-signed certificate is used, this will lead to an ...
If you ignore the certificate warning the encryption still applied, but because it's an unauthenticated encryption, the encryption is useless against active adversary (an MITM adversary that can intercept and modify the data passing through it), as the active adversary can just reencrypt your connection.
The best practice to use self signed certificate in ...
Public and private keys are linked in such as way that if two certificates have the same public key, they were created using the same private key.
So if you assume that the private key is indeed kept private, the part you can trust in the certificates to identify the creator is the public key, and by extension the digest of the public key.
What is the problem of using a self-signed certificate?
Scalability of trust. With a self-signed certificate every client must explicitly trust the servers certificate and whenever the certificate changes the clients must be updated. With a publicly signed certificate the trust in the certificate is derived from the pre-existing trust into the issuing ...
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
The end of section 3.2 states:
This specification covers two classes of certificates: CA certificates
and end entity certificates. CA certificates may be further divided
into three classes: cross-certificates, self-issued certificates, and
Yes, the communication is still encrypted with self-signed certificates.
Self-signed certificates can be made by you, but they also can be made by any attacker. If you insist on using self-signed certificates, I would advice you to mark the certificate as trusted, so that you get a warning if an active man-in-the-middle attack is happening.
Creating your ...
If two self-signed certificates have different public keys you cannot determine if these certificates were created by the same person or not.
If two self-signed certificates have the same public key you at least know that the same private key was used to create the certificates.
If you assume that this secret private key is only known to one person you ...
Not only is the certificate you show self-signed, but it's also a certificate authority, which means that it can issue more certificates for any website.
If you install that certificate into your browser as a trusted certificate authority, then yes, your ISP will be able to do the kind of MitM attacks that you're referencing.
I don't know whether simply ...
You CA certificates has the following extensions:
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
X509v3 Subject Alternative Name: critical
Cryptography has three main security goals:
The certificate in the TLS/SSL handshake is used to provide authentication, i.e. to guarantee the client that he is talking to the intended server and not some Man in the middle attacker. Ignoring a certificate warning will kill this property of the connection.
Does that mean I must distribute to my clients a file, and is that the *.crt file, the *.csr, or the *.key file?
You need to distribute the certificate, i.e. the *.crt file. The *.key file must be kept secret since this can be used to impersonate the certificate. It is only actually needed on the server.
What instructions should they follow to import ...
The CA private key that belongs to the self-signed certificate is only used to sign certificates and, possibly, to sign OCSP responses or CRL's. So besides signing (future) child certificates, it may also required to establish the status of already issued certificates. If this is not expected to happen often then you could store the private key away on an ...
One should stop using MD5 and SHA-1 for digital signatures.
MD5's colliding messages can be found in less than a minute and there are online libraries to produce; corkami and hashclash. Also, SHA-1 is already shattered, that finding two colliding documents are no longer infeasible, and the attack is faster than the generic collision attack O(280). Even ...
There is no point in using HTTPS here.
Since the server and client are both on the same system, communications will occur over the loopback interface, which means the traffic will never leave the machine. To intercept the traffic on the machine itself, the attacker would need administrator privileges. If someone has admin privileges, its already game over.
Considering your self-signed certificate is unique per device (which is absolutely should be), then yes there's massive advantage to using these as opposed to plain text or a shared certificate. This raises the effort required to exploit the process which is the purpose of security features. Yes it can be defeated locally, but not in a repeatable way and ...
Because insecure by default is bad practice.
As with many things, you have to weigh convenience against security. Your proposal would make many people a little bit less secure, by making the life of very few developers a little bit more convenient. This is really not a great deal to make.
In general, software should aim to be configured by default to be as ...
A certificate is a kind of envelope that contains a public key, some attributes defined for what purposes this certificate can be used, and the signature of the issuer.
Without signature there is no certificate. If you don't sign certificate, it is not certificate. You cannot add a plain public key to the trust store, you can only add a certificate.
Let me just draw a MITM for you.
===| When you accept a self-signed cert |===
===| and get lucky |===
+--[Your browser]--+ +--[Server S]--+
| accepts cert A | | has cert A |
| sends +---------------------+...
Encryption is still applied, the issue with self signed certificates is that you have no assurance that the server you are connecting to is who it says it is.
The problem is not so much that they are self signed, it's that they are not signed by some third party you trust. When you browse to a https website your computer checks that the certificate you are ...
While with Let’s encrypt offering certificates free of charge and easily today does take away the “it doesn’t cost anything” argument, there are still reasons why self-signed certificates can be useful, for example
for testing purposes (no CA is giving you a certificate for your local domain like testing.testenv.cooperation)
on local networks (to secure ...
From the comments:
Is this really a CA certificate, i.e. has it basic constrains CA true? ... – Steffen Ullrich
@SteffenUllrich you're right it has: CA:FALSE – little-dude
Signing a certificate requires that the issuer certificate must have the correct flags so that signing is actually allowed. To correctly sign a certificate the issuer certificate ...
You're not far off - copy_extensions is not an extension, it needs to be in the CA_Default section to instruct the CA to copy extensions from the CSR to the signed certificate.
Example below, see the last line:
[ CA_default ]
# Directory and file locations.
dir = /home/ca
certs = $dir/certs
crl_dir = $dir/crl
Consider the case where you control the root certificate verification chain on both server and client (this would be the case when you develop both components). This could include scenarios such as:
Running your own e-mail, database or Web server which only would be used by people whose trusted certificates you can control;
Developing an endpoint or mobile ...
In fact, when importing the public key, duplicate signatures are automatically removed. Because of this, anyone who imports your public key will already have a copy without the redundant signatures. Removing them yourself just makes it so that they do not need to do it themselves.
Is it secured enough if I manually check my certificate?
What you're describing is essentially Certificate Pinning. That being the case, the answer is generally "Yes, it is secure, but it's not a recommended or popular method, due to scalability and maintenance issues."
If this is something your setting up for yourself, it's fine; if you're expecting ...
Is there a simple C library or function to programmatically generate a self-signed Certificate in C on Ubuntu?
One that isn't OpenSSL on a base Ubuntu system? No.
I am looking for a native small stand-alone library just for this purpose with possibly added functionality but not with the full-weight of TLS implementations such as openssl, boringssl, mbedTls,...
In the X.509 universe, checking the validity (i.e. trustedness) of a signature happens after building the certificate chain. That's a process where each (at this stage possibly-invalid) certificate's Issuer field is looked up and matched with a certificate the verifier knows about. It's important to note that the issuer is specified by "Distinguished Name" (...
It actually does not matter for the question if the trust anchor is a publicly trust root CA, a locally trusted root CA or a locally trusted server certificate. What matters instead how to deal with the situation when the trust anchor should not be trusted anymore.
A simple approach would be to have a trust anchor which is valid forever. This is the way you ...
The client certificate is public, just like the server certificate. The only reason to keep the client certificate would be privacy, if you don't want to reveal that you are this particular client. Publishing the client certificate does not allow anyone to impersonate you.
Client authentication does not only require the client to show that it knows the ...