How Can An Unknown Client Connect To A Server?

MrMaui76

Hello,

Long time user, first time poster. I have a situation where I have two identical physical OpenVPN servers. They're running identical configurations except for the server IP address obviously. Today I created a client certificate on server #2 and found that I can connect to server #1 without server #1 knowing anything about the newly created client certificates. How can this be? One helpful hint might be that the client is not receiving the IP address from the CCD file, (mainly because it doesn't exist on server #1), but rather the first IP address from the DHCP pool in the server-bridge configuration option on the server. I admin the servers and they are not sharing a common directory nor are they syncing with each other automatically. I would be happy to provide any information that might be necessary to help me resolve this issue. Hopefully I'm not missing something silly but it's the end of the day and I'm fried.

--
Tony

maikcat

I have a situation where I have two identical physical OpenVPN servers. They're running identical configurations except for the server IP address obviously.

are you using the SAME ca?

Michael.

MrMaui76

Yes Michael, same CA.

--
Tony

maikcat

Yes Michael, same CA.

Thats explains everything...

if your cert is signed by A CA then ALL your openvpn servers use A CA
do recognize the cert...

this is how SSL/TLS works.

ps: how do you think your server *knows* your clients? 😉

Michael.

MrMaui76

I'll admit that I don't quite have a great handle on CAs, keys, and signing. Perhaps I need to start from the beginning on reading some OpenVPN documentation. I've read documentation stating that once a client key was created and distributed, that it could be deleted form the server, but I figured that was a typo. Is it true that a client certificate does not need to exist on a server in order for the client to connect? For my scenario, I was operating under the impression that if there was no CCD file on the server to match the client up with, that the server would recognize this and therefore not allow the connection. Is there any verification that the server does, or can do, so that only those keys that exist on the server itself are allowed to connect? Is the only verification that is occurring coming from the client end, to ensure that it's connecting to a CA that it knows about?

--
Tony

MrMaui76

From reading http://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html it explains that, by specifying "ccd-exclusive " in the server configuration file, that the server will, "Require, as a condition of authentication, that a connecting client has a --client-config-dir file". I believe that this was what I was looking for as when I put that line into my server configuration file, my client now receives the message

AUTH: Received AUTH_FAILED control message
TCP/UDP: Closing socket
SIGTERM[soft,auth-failure] received, process exiting

And when I remove the line my client can connect again. That same page also talks about the client-config-dir option and what happens with that and basically, without the ccd-exclusive option, if the server does not find a ccd file for my connecting client, it will behave exactly like what we're observing and an IP address in the DHCP range specified in my server configuration file will be handed out because of the line "server-bridge 172.16.16.20 255.255.255.0 172.16.16.245 172.16.16.249 #@@ br0 eth0" that exists in my server configuration file. My client consistently receives the IP address of 172.16.16.245 which is the first address in the DHCP range.

Does that sound about right?

--
Tony

MrMaui76

MrMaui76 wrote Does that sound about right?

The real test will be when I configure the server with that option, and then add the client key to the server. Then it should connect, even with the ccd-exclusive option enabled.

--
Tony

maikcat

files needed on server in order openvpn server service to work...

ca.crt
dhXXXX.pem
server.crt
server.key
ta.key (optional)

everything else SHOULD be removed.

again, openvpn uses TLS/SSL you need to read more about how it works,
server does NOT keep any type of client database,it recognize certs by its signature
with that in mind you can generate a cert somewhere else and connect as well...

ccd-exclusive is a secondary form of control...
you can use it to lock someone without revoking its cert.

Michael.

MrMaui76

maikcat wrote server does NOT keep any type of client database,it recognize certs by its signature

Except for the certificate revocation list, right? (Outside of the scope of our discussion, just verifying.)

maikcat wrote with that in mind you can generate a cert somewhere else and connect as well...

But the certificate has to be generated from an identical CA, right? (Like in my situation where there are two separate servers but they're using the same CA.) You can't just generate a certificate on one random OpenVPN server and have it connect to another totally separate system. (Again, just verifying as I find it better to ask, even if it means sounding a little silly.)

maikcat wrote ccd-exclusive is a secondary form of control...
you can use it to lock someone without revoking its cert.

This totally makes sense to me.

--
Tony

maikcat

Except for the certificate revocation list, right? (Outside of the scope of our discussion, just verifying.)

you can say yes....although a CRL is not considered a client database...

But the certificate has to be generated from an identical CA, right?

every cert its signed using the ca.key,thats why ca.key is the MOST significant file in your setup...

so if you are using the same ca.crt in - lets say - 5 installations (which is not the best security option)
then yes , a certificate made for one is accepted in all 5...

my opinion is always create a new CA for each one installation unless you have a valid reason for keeping the same CA.

hope that helps,

Michael.

MrMaui76

hope that helps

Michael,

Yes, that definitely helps. I look forward to reading more about OpenVPN in depth and understanding certificate authorities, PKI, etc. better in the future. Thank you VERY much for your assistance!

--
Tony