Tag Info

Hot answers tagged

32

The purpose of the warning is that by using HTTPS, there is an expectation of proper security, but a self-signed or expired certificate has vulnerabilities that the user needs to be aware of. The "risk" is that one thinks they are properly secured, but they are not fully secured, as opposed to HTTP, where one knows there is no encryption at all. There ...


19

CA signed certs are not actually more secure than self-signed certs, in the sense that the level of encryption is the same. But there is a big difference in the level of trust between the two. Visitors to a site using a self-signed cert have to trust that the cert was generated by the site owner, simply because the site says it is. There is no easy way to ...


18

Security difference First, let's talk about SSL (now called TLS by the way), which adds the 'S' at the end of HTTPS and is in charge of "securing the communication". The clue to answer this question is indeed to fully understand what we mean by "securing the communication". SSL, no matter if it is a self-signed certificate which is being used or one signed ...


7

Any CA which allowed you to buy certs for any domain would likely get their trusted status in common browsers revoked pretty quickly. There have been flaws and bugs which have allowed for this in the past, but they generally get closed when discovered (N.B. this doesn't include nation state level players, who doubtless can abuse the CA model in this way). ...


4

Without warnings for things like self-signed or expired certs, inappropriate cipher suite selections, and other bad HTTPS configurations, the presentation of a website's state of security to the user becomes binary - either you have HTTPS on the site, or you don't. This would hide a number of nuances which can significantly affect exactly how much the "S" in ...


4

Certificates are not about Security at all! Certificates are about Authenticity! The Key inside the Certificate is for the security! The certificate is a way to add some metadata to this key. You can have the same public key in a self signed or in a CA certificate. The security of the encryption will be exactly the same. It's just that with a self signed ...


4

There is no standard way to do what you envision and I'm not aware of any proposals of relevance. The currently established PKI structure allows only for a single certificate chain (i.e. a single issuer for a certificate) and the TLS protocol like used allows only for a single leaf certificate. In theory one might create a certificate with multiple issuers ...


3

In short: You can just start using CertA again, until its expiry date, as the CA is not directly involved when certificates are used. The CA is not directly involved in your use of certificates, unless you revoked the certificate CertA. Revocation means that you go to the CA and explicitly tell them "The certificate CertA was compromised.". There is usually ...


3

You can have a backup certificate from a different CA but you cannot serve multiple leaf certificates (i.e. certificates matching the hostname) within the same TLS connection. You can also not have multiple signatures (i.e. by different CA's) on the same certificate which is a similar question often asked in this context. But you could use different ...


2

A certificate is your public key and some information about the site and then a lifetime. All this is signed by the issuer CA. The certificate is public and thus also the public key, but the private key is not published. One of our SSL certificates has expired and along with that so has the keys. While the certificate will expire the public and ...


2

TLS only allows a single cert. You'd need to have some monitoring in place to check for this issue and automatically reconfigure your web server upon occurrence. You can get the same CSR signed by multiple CAs. Each time you will get a separate cert signed by that single CA. You are likely better off with completely independent keypairs and CSRs for each ...


2

These answers are great. But I often have to give a simplified answer without all the jargon. HTTP - It is not encrypted and the data sent over the line could be easily read. HTTPS - It is encrypted and verified by a trusted party the data is being handled by the correct source. HTTPS (Self Signed) - It is encrypted but there is no verification by a ...


1

Yes, your guessing is correct. OpenVPN has a built-in certificate management feature. This is the role of the Easy-RSA, I am guessing you already know that. The Easy-RSA is an RSA key management package based on OpenSSL. It allows you to build your own root CA and generate and manage the client's certificate/key pairs and the server certificate/key pair. ...


1

Not a full answer, but another thing to think about: with a system like that the easiest way for an attacker to gain access (ie the weakest link) is to steal the private keys to one of those client certs. Things to think about: Are the linux machines physically secure, or do they leave the building (ie laptops)? Do you have good policies for certificate ...


1

It may not be best practice because you're using a specific-purpose CA (in which case, authenticating your OpenVPN clients) for something else, but security-wise, as long as that CA is secure, your solution is fine. I would recommend however putting the private key of that CA certificate somewhere safe, like a smartcard, a completely offline computer or an ...


1

My gut feeling on this would be whether or not there should be recoverable access to archived, encrypted traffic or not. Policy #1 (Destroying all copies of the private key) from Cisco is attempting to: Prevent the old certificate / private key being stolen and used for some kind of spoofing / nefarious activity (even after expiration some things can be ...


1

Assuming your filenames are accurate, so client_cert.pem and client_prv_key.pem actually contain the client cert and privatekey respectively in PEM format: openssl pkcs12 -export -in client_cert.pem -inkey client_prv_key.pem -certfile root_cert.pem -out client.p12 # prompts for the input-key passphrase, then the output passphrase (twice) # to specify ...



Only top voted, non community-wiki answers of a minimum length are eligible