Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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:
Quote:
client
dev tap
proto tcp
remote my server's ip 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert client2.crt
key client2.key
comp-lzo
verb 3
And this is the server.conf file:
Quote:
port 1194
proto tcp
dev tap
ca ca.crt
cert cerc_server.crt
key cerc_server.key # This file should be kept secret
dh dh2048.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.100.0.1 255.255.255.0 10.100.0.201 10.100.0.254
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS my dns"
push "dhcp-option DNS mydns"
push "dhcp-option DOMAIN mydomain.com"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
script-security 2
up bridge-start
down bridge-stop
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.
Last edited by sundialsvcs; 03-27-2017 at 07:30 PM.
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.
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.