6 May 2012 00:32
Re: ns-cert-type not working?
Andre Ruiz <andre.ruiz <at> gmail.com>
2012-05-05 22:32:03 GMT
2012-05-05 22:32:03 GMT
The problem is that there a specific client to the openvpn server that is using server certificates, because it is a server on it's own to another openvpn client. I did not like the idea of generating a different pair of key/cert just to make it look like a client to the server, so in this case it's a server-server (from the point of view of the certificates) connection. But thanks for the advice anyway, I am aware that it is a good practice of security to do that. Andre On Sat, May 5, 2012 at 7:29 PM, Alon Bar-Lev <alon.barlev <at> gmail.com> wrote: > Good to hear it is working. > I guess the problem is that KU was unset. > > You should reach to a state in which clients have "remote-cert-tls > server" in their configuration and server has "remote-cert-tls client" > in its configuration. > > Alon. > > On Sun, May 6, 2012 at 1:21 AM, Andre Ruiz <andre.ruiz <at> gmail.com> wrote: >> Alon, >> >> I think I might have figured it out, or at least walked around it. >> >> I was generating my certificates with TinyCA2, and there is a >> configuration option on the Expert OpenSSL Configuration menu where >> you can set the KU and EKU you want for your keys (for both client and >> server types). >> >> The defaults for a just created CA are: >> >> For a client type cert: >> ns-cert-type = SSL Client, Email and Object Signing >> KU = Key Encipherment, Digital Signature >> EKU = Not Set >> >> And for a server type cert: >> ns-cert-type = SSL Server >> KU = Not Set >> EKU = Not Set >> >> OpenVPN must be checking this attributes on it's own and baffling on >> the "Not Set" parts. With certificates generated that way, openvpn >> will allways give that error and --ns-cert-type and --remote-cert-tls >> seem to have no effect to fix that. >> >> When I changed that parameters (for the server type) to: >> >> ns-cert-type = SSL Client + SSL Server >> KU = Key Encipherment, Digital Signature >> EKU = 1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2 >> >> It worked, with both sides using the server type of certificates. Of >> course now I cannot set the type check, but I can live with that (I'm >> using --remote-tls to check the name and that's good enough). I guess >> the ns-cert-type part did not make any difference, but set it anyway. >> >> My guess, openvpn does not like the attributes not to be set. If they >> are set, then, and only then, you can control/check them with >> --remote-cert-tls. >> >> Strange is that it was working between two v2.0 openvpns, the problem >> started when I put the first v2.2 on the network. Does that mean that >> everyone generating certificates with unchanged default configs on >> tinyca2 will have problems with openvpn v2.2+? >> >> Thanks! >> Andre >> >> P.S.: 1.3.6.1.5.5.7.3.1 and 1.3.6.1.5.5.7.3.2 mean serverAuth and >> clientAuth, can put others if you want. There is a "wildcard" option >> that is 1.3.6.1.5.5.7.3.0, named anyExtendedKeyUsage but openssl does >> not seem to understand it yet. >> >> >> On Sat, May 5, 2012 at 2:50 PM, Alon Bar-Lev <alon.barlev <at> gmail.com> wrote: >>> Hello Andre, >>> >>> Can you please send me your server certificate and one of the client >>> certificates? >>> >>> Thanks, >>> Alon. >>> >>> On Sat, May 5, 2012 at 11:24 AM, Andre Ruiz <andre.ruiz <at> gmail.com> wrote: >>>> Hi Alon, >>>> >>>> Thanks for the answer. >>>> >>>> Is there a default for that options? The manual does not say anything >>>> about defaults and it seems that if you do not explicitly check for a >>>> type, it will accept any type. But even removing all the checks (old >>>> or new ones) I still get the error as if openvpn is trying to force >>>> client/server certificates on different sides by default. >>>> >>>> Using "remote-cert-tls server" on server also did not help, I still get errors. >>>> >>>> Thanks, >>>> Andre >>>> >>>> >>>> On Sat, May 5, 2012 at 4:57 AM, Alon Bar-Lev <alon.barlev <at> gmail.com> wrote: >>>>> Hello, >>>>> These days people should use EKU and not the non-standard netscape extensions. >>>>> Try to use the related parameters. >>>>> Alon. >>>>> >>>>> On Sat, May 5, 2012 at 10:48 AM, Andre Ruiz <andre.ruiz <at> gmail.com> wrote: >>>>>> Hello list! >>>>>> >>>>>> I'm having a hard time with ns-cert-type, it seems not to be working >>>>>> as expected. >>>>>> >>>>>> I understand that it is a security enhancement to check for types of >>>>>> certificates of clients and servers, but if I want, could I use >>>>>> "server"-type certificates on both sides? I would think it's just a >>>>>> matter of not checking it or even specifying to expect type server on >>>>>> both sides. >>>>>> >>>>>> But it's not working. OpenVPN 2.2.1 and 2.2.2, both sides as >>>>>> type=Server on the certificates, both sides without ns-cert-type check >>>>>> (or with ns-cert-type server, it makes no difference), the error is >>>>>> always the same: >>>>>> >>>>>> May 5 04:38:10 vpbjz4 openvpn[6646]: 177.16.213.147:57137 VERIFY >>>>>> ERROR: depth=0, error=unsupported certificate purpose: >>>>>> /C=BR/O=Atendemos_Tecnologia_Ltda/OU=IT_Operations/CN=druid.vpn.atendemos >>>>>> May 5 04:38:10 vpbjz4 openvpn[6646]: 177.16.213.147:57137 TLS_ERROR: >>>>>> BIO read tls_read_plaintext error: error:140890B2:SSL >>>>>> routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned >>>>>> May 5 04:38:10 vpbjz4 openvpn[6646]: 177.16.213.147:57137 TLS Error: >>>>>> TLS object -> incoming plaintext read error >>>>>> May 5 04:38:10 vpbjz4 openvpn[6646]: 177.16.213.147:57137 TLS Error: >>>>>> TLS handshake failed >>>>>> >>>>>> All the places I read suggest that the error "unsupported certificate >>>>>> purpose" is because the server is expecting the type "client" on the >>>>>> client, and that I should fix the certificate. >>>>>> >>>>>> But I have a situation where the same openvpn will act as server to >>>>>> one endpoint and client to another, using the same certs, so there is >>>>>> one of the tunnels where I will have two "server" types connecting to >>>>>> eachother. I do not mind turning that check off (and I know that I >>>>>> could use two different certificates to work around that, but I would >>>>>> like to know the reason as I think it should work). >>>>>> >>>>>> Thanks! >>>>>> Andre >>>>>> >>>>>> -- >>>>>> Andre Ruiz <andre.ruiz <at> gmail.com> >>>>>> Curitiba, PR, Brasil >>>>>> Tel +55 (41) 8407-3847 >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Live Security Virtual Conference >>>>>> Exclusive live event will cover all the ways today's security and >>>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>>> will include endpoint security, mobile security and the latest in malware >>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>>> _______________________________________________ >>>>>> Openvpn-users mailing list >>>>>> Openvpn-users <at> lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/openvpn-users >>>> >>>> >>>> >>>> -- >>>> Andre Ruiz <andre.ruiz <at> gmail.com> >>>> Curitiba, PR, Brasil >>>> Tel +55 (41) 8407-3847 >> >> >> >> -- >> Andre Ruiz <andre.ruiz <at> gmail.com> >> Curitiba, PR, Brasil >> Tel +55 (41) 8407-3847 -- -- Andre Ruiz <andre.ruiz <at> gmail.com> Curitiba, PR, Brasil Tel +55 (41) 8407-3847 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
RSS Feed