1

I want to know that what the security impact is if someone leaks the password of a PKCS12 certificate. I am referring to the password which is required when we export the certificate.

2 Answers 2

1

The password is needed to decrypt the private key stored in the file. Without the file, the password has no value (unless the password is also used for something else, but that should never be done).

If someone has the encrypted file without the password, they can attack the password offline using software like hashcat and GPUs. Depending on the strength of the password, the task of dictionary attacking a password can be anything between trivial to impossible.

If someone has the file and the password, they can decrypt and extract the private key.

With the key, they can ask the CA to revoke the certificate that uses the key, which will cause some denial of service while the site/service operator generates and installs new certificate. This would not even be considered evil by some people.

They can also launch man-in-the-middle attacks against anyone communicating with the site/service, to get user passwords (including admin passwords), see and modify all the private information communicated between the site/service and users, etc. To launch MiTM attacks they need a good network position between the site and the victim user, but it's doable if there is a payout.

If you think the private key for the certificate might have been compromised, generate a new certificate that uses a new key, install it, ensure it is used instead of the old certificate and revoke the old certificate.

For a paid certificate, you should get a new re-keyed certificate with the same end date as your old certificate, and a revocation, for free from your CA.

Webpki certificate revocation is not very reliable (clients like browsers tend to not check whether a certificate was revoked or not). For very high value sites (e.g. a major bank) the browser vendors would push a security update that blacklists the certificate with the stolen key. Otherwise, the stolen key will only become fully useless when the certificate's end time is reached, even if the certificate is revoked. OCSP stapling together with must-staple certificate would help in this case, but it is generally too dangerous to deploy (people judge that the availability problems it causes are worse than the security problems it solves).

2

The password unlocks the encrypted private key of the certificate, so an attacker always needs both, the PKCS-file and a password to successfully use the certificate.

Please mind, that most humans tend to use the same password for more than one purpose, so there are chances that a other person can make his way to the pkcs file with this password (for example a logon on a file server or similar).

How risky this is depends on more factors:

--> For what is sites is this certificate? Are more SANs specified - if yes how critical are the webservers who host this sites?

--> In worst it´s a wild-card certificate. This would give an attacker the chance to issue trustful sites for everything ending with your company name (evil.corp.com, trustme.corp.com,...)

--> How is revocation done in your PKI Infrastructure? Does every single device who checks certificates in your environment do revocation right? There is still the issue that most browsers tend to accept certificates if the CRL can´t be contacted so even that is no 100% solution.

and so on...in most cases you should definitly revoke the certifcate, generate a new private key on the server who needs the certificate and only keep it there nowhere else..

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .