Hi,
On 11/08/17 01:02, Gregory Sloop wrote:
Re: [Openvpn-users] Server vs Client cert generation *SK> On 09-08-17
19:34, Gregory Sloop wrote:
>> I also often need to generate certs for other things and GNU TLS's
>> CertTool works pretty well.
>> I'd like to use one tool to generate all the certificates I generally
>> need - it's just easier to keep track of, document etc.
>> However when I go to generate certs for OpenVPN usage with certtool, it
>> appears I have a problem with the "server" attribute.
>> While I have the following in the certs...
>> ---
>> Extensions:
>> Basic Constraints (critical):
>> Certificate Authority (CA): FALSE
>> Subject Alternative Name (not critical):
>> DNSname: abc-ovpn-server-01
>> Key Purpose (not critical):
>> TLS WWW Server.
>> Key Usage (critical):
>> Key encipherment.
>> Subject Key Identifier (not critical):
>> xxxx
>> Authority Key Identifier (not critical):
>> xxxx
>> ---
>> ...it doesn't appear to be identified as a "server" certificate. [At
>> least in pfsense.]
SK> I have no clue about how to use certtool, but I'll give this a shot.
SK> Do you know what certtool means with "Key purpose"? Is that it's own
SK> invented name for extendedKeyUsage ?
SK> Also, what are you using to check that this is a "server" certificate?
SK> --remote-cert-tls? or --ns-cert-type? or something homegrown?
SK> In any case, this certificate seems to miss the digitalSignature
SK> keyUsage, which is required if you want to use TLS cipher suites with
SK> forward secrecy (DH/ECDH). Modern OpenVPN by default only support
SK> cipher suites by forward secrecy. So although this has nothing to do
SK> with "server" attributes, it is likely to cause the connection to
fail.
*So, follow-up - mostly answering my own questions. [After a boat-load
of tinkering and testing...]
I've successfully used CertTool from the GNUTLS project to create the
CA, Server and Client certs - and also a CRL.
[GNUTLS's CertTool is a CLI tool available under *nix and Windows. My
work was all on the Windows platform, using the most current version,
which at the time this was written was 3.5.8]
What I haven't managed to do, successfully, yet is to use the OpenVPN
client side directive: "remote-cert-tls server"
This really isn't a problem, however. I'll explain that in a moment.
I've not been able to determine what extended certificate attribute
fixes this, despite some significant checking. The benefit of
"remote-cert-tls server" is so that someone couldn't use another
"client" certificate on a MITM server and trick you into connecting to
it, instead of the "real" server.
But there are other ways to ensure the same result that don't rely on
the "server" extended attribute. Follow along and I'll show you one
way that works fine for me.
The docs:
https://openvpn.net/index.php/open-source/documentation/howto.html#mitm
suggest using "tls-remote" which has been *deprecated.* and bombs in
recent OpenVPN clients. [Someone ought to update that!]
However, there's a replacement:
--verify-x509-name your-servers-certificate-cn-name-here name
You can also use the whole subject name, if that makes you feel
better, or several other options. [See the docs and google for more...]
That option subsequently allows me to not worry about finding the
exact proper yet elusive extended-attribute in my certificates - while
still allowing for strong verification that I'm connecting to exactly
the server I intend.
[If you have several servers, there are other options too, for name
matching that will likely help. But this way is far more than adequate
for the 99.9% of us running small OpenVPN servers of our own. If
you're larger, I'm sure you have the resources to figure it out. If
you do, I'd be glad to hear the solution to make CertTool generate the
proper "server" certificate.]
you're protecting yourself from different things here:
- "remote-cert-tls server" prevents someone from using a client
certificate to pose as a server certificate
- "verify-x509-name" ensures that openvpn checks the server name against
the certificate name
with the first option, you are not required to have a valid FQDN for
your server; the second option is more strict because it allows clients
to connect *only* to servers identifying themselves as the FQDN you
specify - this tends to not scale very well if you have multiple
connection blocks or "remote" entries in your client config files.
---
What's interesting is: pfSense doesn't think the certificates
generated by the *EasyRSA* tool are server certs either. [It's
possible that pfSense is mistaken - I just found it amusing.]
I also don't recall actually trying them [the EasyRSA certs], even
with that warning, using "remote-cert-tls server". When pfSense
complained about even the EasyRSA cert not being "server" certs when I
added them, I simply gave up. [I didn't really want to use EasyRSA
anyway. I was just testing a bunch of different things trying to get
the same attributes on CertTool generated certs as EasyRSA does - but
without avail.]
---
So, just to document, should anyone else stumble across this - here's
the steps to duplicate my work using CertTool. This is, IMO, better
than using EasyRSA and *far* less confusing and daunting than
OpenSSL's CLI tools. [Holy cow, the OpenSSL tools are more like
learning latin or worse - you might get by cut/pasting someone else's
work, but you won't likely have a clue what you're doing or why.]
So, here's the process to use CertTool
#Create a CA key, and self sign the certificate using that key.
---
certtool --generate-privkey --outfile ca-key.pem XXXX [Where XXXX is
the RSA key size]
certtool --generate-self-signed --load-privkey ca-key.pem --outfile
ca-cert.pem --template=ca-template.txt [I'll cover this "template"
file down the way.]
---
# I have a batch file that generates a temp template file with the cn
and DNS names for this cert, and I pass the proper values... I'm glad
to share details if you want.
# This same procedure generates server or client keys and certs -
using a different base "template" for each [server or client]
---
certtool --generate-privkey --outfile %1-key.pem --bits=%2
--template=tempfile2.txt
certtool --generate-request --load-privkey %1-key.pem --outfile
%1-request.pem --template=tempfile2.txt
certtool --generate-certificate --load-request %1-request.pem
--outfile %1-cert.pem --load-ca-certificate ca-cert.pem
--load-ca-privkey ca-key.pem --template=tempfile2.txt
---
I've tried certtool as well and ended up with a "TLS Web Server"
certificate using this cert.cfg file:
---
organization = "Cookbook 2.4"
country = US
cn = "newserver"
#dn = "cn = Nikos,st = New\,
Something,C=GR,surName=Mavrogiannopoulos,2.5.4.9=Arkadias"
expiration_days = 1000
tls_www_server
signing_key
encryption_key
---
and 'openssl x509 -text' does indeed give me:
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
which is identical to the output generated for a certificate using
EasyRSA's "build-key-server" script.
HTH,
JJK
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
