23

All the OpenVPN/Easy-RSA tutorials that I've found, advise to setting an empty challenge password while building the key for the OpenVPN server.

  • Anybody knows why? What's the intended use for the challenge password in Easy-RSA server's keys?

  • And what about client's keys? I see that a build-key-pass exists to generate encrypted client keys, but no server equivalent exists. Still, both build-key and build-key-pass ask for a challenge password.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
Giacomo Tesio
  • 371
  • 1
  • 2
  • 7
  • Have you had a look into SCEP recently? Even the concept itself if not the code of jscep will make clear what the challenge password is used for. – emden09 Mar 28 '19 at 16:56

2 Answers2

31

"Challenge password" is an obscure and usually useless feature. -> Leave empty.

If your CA allows this, then the Challenge Password will be required of anyone who tries to get the cert revoked. -- But from what I understand there are few (or none?) CAs that actually use this. (Please leave a comment if you know otherwise.) So leave it empty if you're unsure.

What's the intended use of a "Challenge Password"?

As far as I understand it the idea is this:
If you have a rogue admin who has access to the cert and key then that admin could revoke the cert and DOS you.

But if you have a CA that will challenge the rogue admin to supply the "Challenge Password", then the rogue admin may not have that password and then you're safe from that DOS.
(The CP is NOT included in either cert or key. Only in the CSR. And you don't need the CSR for daily operations, so presumably operations personnel might not come into contact with the CSR file and therefore not know the Challenge Password.) (But bear in mind that you still have to worry about a rogue admin who has your cert/key. A lot. So from my understanding you gain exactly nothing from having a "challenge password" in the first place. -- Correct me if I'm wrong. I've got the feeling I'm missing some essential idea here. -- Maybe this is meant to allow revocation by somebody holding just the certificate and the password but NOT the private key.)

Further reading

The (too short) official definition is here: RFC 2985: PKCS #9: Selected Object Classes and Attribute Types Version 2.0, Section 5.4.1: Challenge password

The question comes up regularly:

Further source:

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • There is no such thing as rogue admin. You may have a limited trust but you have trust nontheless. CSR challenge has plenty of use cases in very specific situations. If you dispose of CSR properly it can be treated as a secret (I know it is plaintext in the CSR, that is not the point). If you use a split secret scenario you may build an environment where revocation is only possible upon agreement of both user and issuer of the certificate. Issuer types in half of the password and the requester types in the half, then trusted 3rd party takes care of the CSR handling. – nethero Feb 07 '20 at 09:29
3

The most easy answer for why the empty password is pretty simple. your not going to be around to ENTER said password when the service starts / restarts. and the ONLY way to reliably have the server key work in that scenario is to have an empty key.

its the same reason for why HTTPS server keys are "empty" passworded.

LvB
  • 8,217
  • 1
  • 26
  • 43
  • 3
    But isn't that what encrypted keys are for? I mean an encrypted server key would require a password on service startup. I suppose the password for encrypted keys is something different from the challenge password. – Giacomo Tesio Dec 29 '14 at 11:02
  • 1
    your confusing 2 things here I belief. encrypted keys are security keys that have been encrypted. and security keys can be used to encrypt a data connection. the service needs to access the security key at start up to validate the connections being made to it. It can't read encrypted keys. so you need to decrypt your key in some way before the program can access it. Setting this up is HARD, and for easy of use the tutorials just do not encrypt the key. Encrypting the key is also often moot as the password is stored on the system (e.a. an attacker can read the password) – LvB Dec 29 '14 at 11:11
  • 1
    This answer is confusing Challenge Passwords and encrypted keys. They are not the same, but the reasoning here applies to encrypted keys, not challenge passwords used for revoking the key at the CA. It's basically a nonce. See https://serverfault.com/a/266258/72176 – oligofren Jan 22 '18 at 15:44
  • 1
    @oligofren, you are entirely right. I'll add that you should never use "empty" passwords on the SSL key in production networks. Depending on the level of security required, you either use the .p12 package with strong password or HSM to store the SSL keys. You always want to protect your private keys. With a proper separation of duties, you may even use encrypted passwords in your configuration if you have enough people. – nethero Feb 07 '20 at 09:20