Re: [Openvpn-users] Server vs Client cert generation
Hi, On 29/08/17 22:06, Gregory Sloop wrote: Re: [Openvpn-users] Server vs Client cert generation 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.] my cert shows the exact same output as yours: Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Purpose (not critical): TLS WWW Server. Key Usage (critical): Digital signature. Key encipherment. Subject Key Identifier (not critical): 40f4ad5fa5a1b1f01642a4420c623b496af85e4a Authority Key Identifier (not critical): 28142f46f3db31a807404e0d5c9af3490f6caab9 as the "Key Purpose" is not critical; I've just tested this certificate on a server, connected a client to it with 'remote-cert-tls server' enabled and it works just fine. BTW: This was using OpenVPN 2.4.3 on the server, 2.4.0 on the client. What happens if you use your cert and connect a client with "verb 5" set? you should see log messages similar to VERIFY KU OK and VERIFY EKU OK. HTH, JJK Thanks for the follow-up. Let me do some testing, and I'll get back to you. [I hope I kept all the old certs...so I don't have to generate those again.] It might be a few days - but I'll try to clear time to do it. -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
Re: [Openvpn-users] Server vs Client cert generation
Hi, On 29/08/17 22:06, Gregory Sloop wrote: Re: [Openvpn-users] Server vs Client cert generation 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.] my cert shows the exact same output as yours: Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Purpose (not critical): TLS WWW Server. Key Usage (critical): Digital signature. Key encipherment. Subject Key Identifier (not critical): 40f4ad5fa5a1b1f01642a4420c623b496af85e4a Authority Key Identifier (not critical): 28142f46f3db31a807404e0d5c9af3490f6caab9 as the "Key Purpose" is not critical; I've just tested this certificate on a server, connected a client to it with 'remote-cert-tls server' enabled and it works just fine. BTW: This was using OpenVPN 2.4.3 on the server, 2.4.0 on the client. What happens if you use your cert and connect a client with "verb 5" set? you should see log messages similar to VERIFY KU OK and VERIFY EKU OK. 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
Re: [Openvpn-users] Server vs Client cert generation
Hi, snippety-snipped ;) On 29/08/17 21:06, Gregory Sloop wrote: > Any insight you can shed here would be fab. [Or anyone else, for that matter.] > Re: verify-x509-name > [Or use the "-name-prefix" option in --verify-x509-name technically, that is "name-prefix" The example in the manual shows how "Server- name-prefix" works for servers named Server-1 and Server-2 etc. The dash is currently mis- aligned. but there is a patch awaiting approval on the dev ML. Regards -- 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
Re: [Openvpn-users] Server vs Client cert generation
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. ] 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. --- I've tried certtool as well and
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): >> >>Authority Key Identifier (not critical): >> >> --- >> ...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
Re: [Openvpn-users] Server vs Client cert generation
Hi, 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): > >Authority Key Identifier (not critical): > > --- > ...it doesn't appear to be identified as a "server" certificate. [At > least in pfsense.] I have no clue about how to use certtool, but I'll give this a shot. Do you know what certtool means with "Key purpose"? Is that it's own invented name for extendedKeyUsage ? Also, what are you using to check that this is a "server" certificate? --remote-cert-tls? or --ns-cert-type? or something homegrown? In any case, this certificate seems to miss the digitalSignature keyUsage, which is required if you want to use TLS cipher suites with forward secrecy (DH/ECDH). Modern OpenVPN by default only support cipher suites by forward secrecy. So although this has nothing to do with "server" attributes, it is likely to cause the connection to fail. As always, post logs and configs if you want better answers. -Steffan -- 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
[Openvpn-users] Server vs Client cert generation
So, IMO, EasyRSA is pretty broken. [I'll skip the discussion about why. Go try to run it on Windows and see how that works, then then we can talk. Also, key encryption defaults.] 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): Authority Key Identifier (not critical): --- ...it doesn't appear to be identified as a "server" certificate. [At least in pfsense.] But looking at the certificate info between some EasyRSA certs and the CertTool ones, they both have the same extended attributes for Client vs Server. --- Here's an EasyRSA one... Extensions: Basic Constraints (not critical): Certificate Authority (CA): FALSE Subject Key Identifier (not critical): Authority Key Identifier (not critical): Key Purpose (not critical): TLS WWW Server. Key Usage (not critical): Digital signature. Key encipherment. --- Here - they appear to be very similar, both having the "Key Purpose" of "TLS WWW Server" - so I'm puzzled. So, if the "TLS WWW Server" attribute isn't the proper one, which is? [Better yet, does anyone have a certtool example? Or a template file (which is how I generate them) that produces the proper cert?] TIA -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
