0

My question is regarding the non-repudiation in TLS with the use of Java keystores and truststores. The root and intermediate certificate located inside the keystore and truststore, they verify another certificate. If they are manipulated they could potentially verify a wrong certificate.

Normally when generating a new certificate the certificate authority checks the chain of trust and sees if the certificate is coming with the right intermediate and root certificate. But what if the attacker manipulates the certificate as well?

If the attacker could hack the password would it then potentially for him not be possible to change the certificate?

I know one improvement is to use a better hashing, for example, using SHA-512 instead of SHA-256. Another one would to make sure that the certificates can only come form certain certificate authority.

Are there any other improvements known to protect the root and intermediate certificate?

Are there other limitations known to TLS?

Paul Velthuis
  • 325
  • 4
  • 15

1 Answers1

2

The root and intermediate certificate located inside the keystore and truststore, they verify another certificate. If they are manipulated they could potentially verify a wrong certificate.

The truststore contains the root certificates of the accepted certificate authorities (CA). Usually it does not contain the intermediate certificates. The truststore must be kept secure because if it is manipulated (as you said), you could accept an unwanted certificate.

The keystore contains client certificates, not trusted ones.

Normally when generating a new certificate the certificate authority checks the chain of trust and sees if the certificate is coming with the right intermediate and root certificate. But what if the attacker manipulates the certificate as well?

The certificate authority does not check any chain. You provide a CSR (Certificate Signing Request) to the CA, which is a certificate request signed with your private key. The CA generates the certificate, signs it with CA's private key, and returns you the certificate and the chain. See Certificate enrollment process

The attacker can not manipulate the certificate because it does not owns the private key of the CA, and the verification with the public key of the trusted root will fail.

if the attacker could hack the password would it then potentially for him not be possible to change the certificate?

A certificate is public. The corresponding private key is private. To proof you owns a certificate is to perform a digital signature with the private. So to "hack" a certificate the attacker needs the private key. (A private key can be protected with a password, but this is related with how the private key is stored)

I know one improvement is to use a better hashing, for example, using SHA-512 instead of SHA-256.

I think this is not related with the question

Another one would to make sure that the certificates can only come form certain certificate authority.

Of course, this is the purpose of the truststore. The way a certificate is added to the truststore is outside the scope of TLS

Are there other limitations known to TLS?

Please detail...

pedrofb
  • 37,271
  • 5
  • 94
  • 142