So a few observations and possible clues/issues:
I should probably do another test, though I'm worn out from all the hassle of
the last go-round. [But I think I kept all the "test" certs I used, so testing
should be easier...]
But I think your cert shows:
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
and while I don't have the > text from openssl, I do have it from certtool, and
it shows:
Key Purpose (not critical):
TLS WWW Server.
[Critical vs not critical]
I don't know what difference that makes in the cert/key - but that's the only
difference I see. [And, IIRC, that cert/key that's "TLS WWW Server" but non
critical *fails* when I try to use the OpenVPN directive "remote-cert-tls
server." But the EasyRSA generated one, like yours works fine.]
I haven't been able to determine how to make the extension/constraints
"critical" in CertTool, so I can't test if that's the problem/issue.
Any insight you can shed here would be fab. [Or anyone else, for that matter.]
---
Re: verify-x509-name
Yeah, I understand the difference. [Specific DN vs "Server" extension cert/key]
But you don't have to match on the exact DN. You just have to make sure the DN
is "unique enough" that no client cert could have that partial DN, and use
something like:
--verify-x509-name ovpn-server.fancydomain.com name
That should match 1.ovpn-server.fancydomain.com, or
blah.ovpn-server.fancydomain.com etc. [I was pretty sure I tested this.]
[I think it will also match server1-ovpn-server.fancydomain.com, though I've
not actually tried that kind of a match. Essentially, I believe, it will match
anything as long as it ends in ovpn-server.fancydomain.com (I should note, I
could certainly be wrong - but that's how I remember it.)]
So, that helps get around the "multiple" servers issue.
[Or use the "-name-prefix" option in --verify-x509-name; though this gets more
complicated, IMO.]
But I'd prefer to have the ability to match on either:
--remote-cert-tls server or --verify-x509-name - which I don't believe I can do
with the certtool certs.
My solution was simply to find a way "around" the problem since I couldn't find
any way through it. I'm willing and able to spend some time to flesh out a way
through if someone has some concrete ideas and thoughts. [Something better than
- "Hell, why not just try X? It _might_ work!?"]
---
I'm pretty much done using EasyRSA - IMO, it's badly supported, does really odd
things [or makes odd choices] can't be used for a number of other things easily
and I don't know a lot of what's going on under the hood so-to-speak.
For an example of a problem in EasyRSA: For years now, EasyRSA uses "-new"
instead of "genpkey" - which defaults to generating an encrypted key with 3DES,
rather than something that is viable for use in the modern age. [AES128/256+]
So, to get keys that are reasonably protected, you have to use the option to
"change" the passphrase after you generate the cert/key pair, and that's a
stupid extra step. And this isn't the only goofy thing that's wrong with
EasyRSA. The current version is simply broken. I reported the problem a long
time ago, and it's not fixed [to my knowledge], and there's been no maintenance
release to fix the problem - or even a real response. It's not a earth-shaking
horrible problem that's super-difficult to fix, but we shouldn't be continuing
to offer software that's totally broken. (You can't do ANYTHING in Windows
without the "fix.")
CertTool is pretty clear what's going on, is pretty easy to use [with a few
rudimentary batch files] and I can use it for generating certs for things like
rsyslog TLS certs - where EasyRSA's certs bomb. [It's kind of like the choice;
Use iOS, use Android, or compile AOSP yourself. Using EasyRSA is like iOS,
except unlike iOS, it's horribly broken besides. CertTool is like Android. And
OpenSSL is like compiling AOSP yourself. <shudder>]
So, I'd really like to get CertTool to work with "--remote-cert-tls". It's
multi-platform - and one could hack together some pretty simple scripts to do
what's needed. IMO, more viable than EasyRSA.
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.
---
<SNIP>
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.
------------------------------------------------------------------------------
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
