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.]
---
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
---
The template file is documented here:
https://www.gnutls.org/manual/html_node/certtool-Invocation.html
---
Be aware of the following specific items in the template - as they apply
specifically to OpenVPN.
For the CA, have these in your template: [This isn't a comprehensive list - but
the relevant items for what's appropriate for a CA vs Server cs Client type of
certificate.]
---
ca
signing_key
encryption_key
key_agreement
data_encipherment
cert_signing_key
crl_signing_key
#BUT *NOT* THESE!
tls_www_client
tls_www_server
===
For the Server, have these in your template:
---
signing_key
encryption_key
key_agreement
data_encipherment
tls_www_server
#BUT *NOT* THESE!
ca
tls_www_client
cert_signing_key
crl_signing_key
===
For the Server, have these in your template:
---
signing_key
encryption_key
key_agreement
data_encipherment
tls_www_client
#BUT *NOT* THESE!
ca
tls_www_server
cert_signing_key
crl_signing_key
===
---
Generating the CRL goes like this:
certtool --generate-crl --load-ca-certificate your-ca-certificate-name
--load-ca-privkey your-ca-key-name --load-certificate
a-concatenated-list-of-revoked-certs-in-one-file > CRL.pem
It will ask you about the number of days for CRL validity - I just put in 3650.
That may well exceed the lifetime of the CA and certs [because you'll likely be
cranking the CRL's long after you initially generated the ca and certs with 10y
lifetimes], but that's fine - better than not long enough. [And it doesn't add
any additional security risks having the CRL life exceed that of the CA/Certs.]
---
Hope that helps someone.
-Greg
------------------------------------------------------------------------------
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
