Hi,
I'm trying to configure an openvpn server. Well, actually it worked for a while until I rebuilt the ca, the certificates and the private keys. I'm connecting to a Centos 7 from a Mac (using tunnelblick - which works just fine when connecting to other server and worked on this server also before this).

I created a new client pair of certificate/private key and when I was prompted for a password, I simply pressed enter, meaning (as far as I know) that there would be no passphrase to ask for (at least when I generate ssh keys, this is how it works).

But now when I try to connect to it, I get the following error from tunneblick:
"The passphrase was not accepted." I don't really understand it. Could it be a bug?
Anyway this my client-side config:
And this is the server.conf file:
Another question, which might be even more important is: how does the association between the key/certificate pairs is being made? I don't understand why the certificate and the private keys are both on one side. So how does openvpn know that the client is legitimate? I'm guessing there's an association between the CA (which is common to both the server and the client) and the certificate. If that's the case, how can I check it?

You might have been confused by "challenge passwords." (Just guessing ...)

In the ordinary process of generating a certificate using, say, EasyRSA, you will be prompted for a "Challenge Password." You should in all cases (usually) just press "Return," to omit creating such a password. (More information here ...)

In my experience, "challenge passwords are irrelevant."

When you are using certificates to provide security (as you always should ...), those certificates don't involve passwords, unless you elect to use the build-key-pass command to create an encrypted certificate that does require entry of a password in order to unlock (decrypt) it. The exchange of credentials between client and server ought not require the additional input of further secrets from you.

Actually I did solve the problem yesterday. To me this is a bug. Just to make sure, I tried using the same configuration files on the openvpn client in Windows. The error was the same (something regarding the private key not working). What I did was to clear the passphrase from the the private key, using openssl -in client.key -out client.key. I used the new key and I got a little bit further. And here I came across another error saying that it could not verify the local certificate. Then I realised that the server's certificate was the problem. So I recreated it (./build-key-server), and then it worked.

So in my opinion there were to unrelated problems. But the first one (the one I was complaining about) is really annoying and I consider it a bug. In other cases creating the certificate/key pair was no trouble.

No, this is documented behavior. The server certificate should not be encrypted with a passphrase, AFAIK. I know of no way to supply a passphrase and of course it would be rather silly anyway.

The server's key should be built as a "server key," and all clients should be instructed to check for this attribute.

I set up OpenVPN with a /etc/openvpn directory owned by root and with a -rwx------ permission mask. I don't bother to tell it to demote itself to nobody.

I don't think you really followed what I said. I didn't say that using a passphrase for the certificate key was a bug. I know there shouldn't be any passphrases. The problem is that every time I build a new certificate/key pair, there seems to be a passphrase inserted in the private key, even if I simply press enter when I'm prompted for a password (when running ./build-key). I inferred that this is a bug. As soon as I ran openssl -in client.key -out client.key, and used the new file it seemed to work (it didn't say that there was a problem with the private key anymore, it said that. It wasn't the server's key, it was the client's key.

The second error was not related to the first error. Having authenticated the client's certificate, the vpn said that it couldn't verify that local certificate. But that's another story.

Very strange. My copy of EasyRSA doesn't do that. "build-key" has no password, "build-key-pass" does. Is your version up to date?

Well, it didn't do that before either. It is up to date to the extent that Centos repositories are up to date: 2.2.2-1.el7. Anyway, I read about this (seemingly rare) problem on the internet and someone had the same problem and he solved it by running the aforementioned command. And that was that