34

CA A revokes CA B, does certificate C become invalid? Yes, revocation cascades down to the tree. If CA certificate is revoked, all certificates below (regardless of how many levels are below CA) are implicitly considered untrusted. Keep in mind that they become *untrusted*, not revoked. CA A gets revoked (somehow), does its revocation cascade all the way ...


28

This will mean a lot of unneeded overhead. I'd suggest following: Since you don't have certificates issued by CA, create your own CA. Namely, create a self-signed certificate and add it to a key store on both servers, so that your certificate is trusted. Issue certificates to each server and sign them with private key of your own CA. Make your servers use ...


21

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


16

No, HSTS does not protect against certificate misissuance. HSTS simply tells the browser to only allow connecting to that site over HTTPS, it doesn't have anything to do with checking whether the certificate should be trusted. There are two things that can help with misissuance to some extent, Certificate Transparency (CT) and Certificate Authority ...


16

Is identity certificate same as public key? No, a certificate contains a public key but is not the public key itself. If no, then is identity cert considered a secret? Usually not, it usually contains only information not considered secret. How are they related? A certificate is the public key of an identity together with more information about the ...


13

No, I don't think that the solution is good. Let’s go through it: This is fine If we can manually copy, why not copy the public keys directly? Here's the real problem. As this is done on an insecure connection, you can't be sure that the first server actually talks to the second server. You weren't specific on how the exchange works, but using the token ...


9

"It depends". The most secure answer is "yes, it revokes the subtree", because once the "B" certificate has been revoked there's no reason to trust any certificate it claims to have issued (or any CRL it has signed, et cetera). But it really depends on what inputs are given to the chain builder (which means it won't be consistent from application to ...


9

Steffen Ullrich gave a good answer. I would just add a few more points. The main idea of certificate is that there is some party (called CA - Certification Authority) that is trusted by all PKI participants, which confirms the ownership of the public key. You can interpret certificate as statement: "We, the CA, confirm, that this public key belongs to ...


8

If you renew (same key, same name) the Root CA certificate then the leaf certificates will still validate. A certificate's identity is defined by its key and name, and if neither change then it's effectively the same certificate. All a renewal does is change the validity period of the original certificate. Contrast the above with a re-key (new key, same ...


6

No, but. Yes, technically you sign (or decrypt) with the privatekey, not with the certificate itself. And a publickey certificate never contains the privatekey. But a lot of software, and thus documentation, and other description, blurs this distinction. We generally use a privatekey with a certificate (with the exception of SSH, where we attach limited ...


6

There is no way to combine multiple certificates into a single entity which then can be provided to the client for validation. It is also not possible to send multiple leaf certificates within the TLS handshake to the client in the hope that the client will pick the matching one. The common way to deal with many names is instead to have many certificates ...


6

The only way to establish initial trust between two servers separated by an untrusted network has to involve a manual1 step. This can be achieved either by copying it manually or by manually comparing whether the keys are transmitted correctly before trusting them. The manual comparison is typically done using a key fingerprint. It can be done by comparing a ...


5

I found the following simple method to remove the locally trusted CA certificates not present in the official and current Microsoft Certificate Trust List: First download Sigcheck (https://docs.microsoft.com/en-us/sysinternals/downloads/sigcheck) and then execute: >sigcheck.exe -tuv ... Listing valid certificates not rooted to the Microsoft Certificate ...


5

For a Diffie-Hellman key exchange the shared secret created will be the same if the same key pairs are used. This means that if Eve gets hold of a private key of either sender or receiver then they can compute the shared secret and decrypt all past and future messages between Alice and Bob. The common way to get around this problem is to use ephemeral keys ...


5

The former is correct, as verified by RFC 2986: PKCS #10: Certification Request Syntax Specification: The process by which a certification request is constructed involves the following steps: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes ...


4

Yes, there's a reason; public key encryption is very slow and CPU-intensive, and not at all suitable for encrypting chat data, which may well include images, audio or video as well as text. That's why wherever it's used, it's only used to transmit a shared symmetric encryption key which is then used to encrypt the actual content. But in any case, it's never ...


4

This logic is in the configuration (i.e. openssl.cnf) only. There is likely something like countryName = match in it. It makes sense to have such policy for a company CA where the company is only in a single state (and such policy is often together with organizationName = match). But it does not make sense for a some globally acting CA which issues ...


4

(CW for anyone who wants to add additional cases) The size/strength of ephemeral keys for DHE and ECDHE key exchanges in TLS can depend on the protocol (version) the server-side implementation code (usually a library), and sometimes configuration the client-side implementation (ditto) First, there is a significant difference between TLS 1.0 through 1.2 (...


4

OCSP responses may be signed not only by the CA itself, but also a designated OCSP signer. That's an X.509 certificate issued by that CA with the OCSPSigning (1.3.6.1.5.5.7.3.9) extended key usage. For details see RFC 6960, section 4.2.2.2.


4

How can I validate, that the cert certifies exactly that key? A certificate does not "certify" a key. What you describe is to check if the private key matches the public key in the certificate and thus can be used to prove ownership of the certificate against a third party. And yes, it is enough for this to check that the public key you have in the key pair ...


4

There is no restriction in TLS itself which prevents using the same key pair on both sides of the connection. It is not really a good idea since a private key should be kept private (which it really isn't when shared between client and server) but it should nevertheless work.


4

Question #1: With Bob's key and the traffic, could Eve now decrypt all content Bob has ever sent to Alice? Yes. It is about "forward secrecy" and it depends on how Threema manages session keys. (From wikipedia: "Forward secrecy protects past sessions against future compromises of secret keys or passwords.") There are two points to consider: Ephemeral ...


4

This is known as a 'known plaintext' attack. All modern encryption algorithms are designed to be resistant to this type of attack. Many types of files contain known plaintext. For example, PDF documents begin with the header '%PDF'. Other information in most PDF documents is easy to guess, such as embedded fonts, formatting info, etc. If known plaintext ...


4

This sentence is technically correct, but confusing. The CSR contains the public key. The CA does “create” a public key as an intermediate step in generating the certificate, but all it does is to copy it from the CSR, and then embed it in the certificate. It's true that the knowledge of the public key doesn't compromise the private key, but the CA never had ...


3

Put multiple public keys in the firmware, with the corresponding private keys stored in diverse locations. Require that updates are signed with all of the private keys, not just one key. Never bring the private keys together, not even for code-signing — instead, move the code around between the locations where the private keys are stored so that each one can ...


3

With OpenSSH it's not possible. As said by @TildalWave you need to use the fork from Roumen Petrov PKIXSSH. Once you have your X509 certificate you don't need to add the public key on the authorized_keys file. You need to configure two things in the server side: Add the certificate for the CA in the directory set by CACertificatePath directive in ...


3

There are a few options that may help you here, but there's no guaranteed way to stop this: Depending on your infrastructure, you may be able to use Name Constraints to limit your other administrator's CA to a specific subdomain or to a specific Distinguished Name arc. Whether that helps you or not, depends on your specific circumstances. For example, if ...


3

It should be secure overall, but it's not as secure as a direct communication (endpoint <-> website) would be, because there is another section that could get compromised (endpoint <-> proxy <-> website) by the attackers and leak your data. If they want to, they can snoop on everything you are doing and you have agreed to that by signing your work ...


3

Old question, but I'm studing a similar architecture on AWS, and has been a long journey. The first question to answer is if is possible to configure AWS load balancers (ELB at the time, ALB and NLB now) to perform mutual TLS authentication. This requires understanding of the mutual TLS authentication works. A google search can help you more than a ...


3

Simple solution would be to discontinue the use of the existing key pair, generate a new Public / Private key pair and deploy them in place of the old ones.


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