> > >Folks > >I would like to have my windows 7 laptop communicate with my home >server via a VPN, in such a way that it appears to be "inside" my >home network. It should not only let me appear to be at home for >any external query, but also let me access my computers inside my home. > >I already have this working using M$'s PPTP using my home Centos 6 >gateway/router as the PoPToP server. However, I am concerned about >the privacy/security of such a connection. > >I have seen discussions of OpenVPN, OpenSwan, LibreVPN, StrongSwan >(and probably others I haven't noted). I'd be interested in hearing >from anyone who wishes to comment about which to use, with the >following requirements: > >1) As noted, it should be secure (anti NSA?) >2) Works on Centos 6 and Centos 7 and Windows 7 (and for the >future, Windows 10) >3) Can be set up on the server with command line interfaces only (no GUI) > >And, should not be a nightmare to set up. > >Any thoughts? > >David---------------------------- FOLLOWUP & REPORT I had lots of suggestions, and the most persuasive was to try OpenVPN. I already had a CA working, so issuing certificates was easy. The HOW-TO guides were less helpful than I could hope, but comparing several of them, applying common sense, and trying things out, I arrived at a dead-end. Here's essentially what happened: - None of the HOW-TOs were very clear about the need to add some attributes to a certificate, keyUsage and extendedKeyUsage. They had different values for server and client. OpenSSL documentation was a big vague on how to add them, but I think I did - the print out of the entity certificates showed the values. The attempt to connect failed. The client log is below. I think it's complaining that the CA certificate doesn't have the ke Usage extension, which makes no sense to me. Such an extension should be in the end-entity certificate, not the CA's, unless I'm wrong. I checked the server and really think that the certificates are in the right place. To review the situation: Client: A windows 7 laptop, and it definitely moves around. Server: Centos 6 running in my home. Protocol is TCP Client log, some details replace with XXXXX --------------------------- Mon Apr 18 05:34:47 2016 OpenVPN 2.3.10 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 10 2016 Mon Apr 18 05:34:47 2016 Windows version 6.1 (Windows 7) Mon Apr 18 05:34:47 2016 library versions: OpenSSL 1.0.1s 1 Mar 2016, LZO 2.09 Enter Management Password: Mon Apr 18 05:34:47 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 Mon Apr 18 05:34:47 2016 Need hold release from management interface, waiting... Mon Apr 18 05:34:48 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 Mon Apr 18 05:34:48 2016 MANAGEMENT: CMD 'state on' Mon Apr 18 05:34:48 2016 MANAGEMENT: CMD 'log all on' Mon Apr 18 05:34:48 2016 MANAGEMENT: CMD 'hold off' Mon Apr 18 05:34:48 2016 MANAGEMENT: CMD 'hold release' Mon Apr 18 05:34:48 2016 Socket Buffers: R=[8192->8192] S=[8192->8192] Mon Apr 18 05:34:48 2016 MANAGEMENT: >STATE:1460982888,RESOLVE,,, Mon Apr 18 05:34:48 2016 Attempting to establish TCP connection with [AF_INET]X.X.X.X:1194 [nonblock] Mon Apr 18 05:34:48 2016 MANAGEMENT: >STATE:1460982888,TCP_CONNECT,,, Mon Apr 18 05:34:49 2016 TCP connection established with [AF_INET]X.X.X.X:1194 Mon Apr 18 05:34:49 2016 TCPv4_CLIENT link local: [undef] Mon Apr 18 05:34:49 2016 TCPv4_CLIENT link remote: [AF_INET]X.X.X.X:1194 Mon Apr 18 05:34:49 2016 MANAGEMENT: >STATE:1460982889,WAIT,,, Mon Apr 18 05:34:49 2016 MANAGEMENT: >STATE:1460982889,AUTH,,, Mon Apr 18 05:34:49 2016 TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=63eed44a 8be061de Mon Apr 18 05:34:50 2016 VERIFY OK: depth=1, C=US, ST=California, L=San Francisco, OU=Certificate Authority, O=XXXX, CN=X.X.X Mon Apr 18 05:34:50 2016 Certificate does not have key usage extension Mon Apr 18 05:34:50 2016 VERIFY KU ERROR Mon Apr 18 05:34:50 2016 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Mon Apr 18 05:34:50 2016 TLS Error: TLS object -> incoming plaintext read error Mon Apr 18 05:34:50 2016 TLS Error: TLS handshake failed
On Mon, 18 Apr 2016, david wrote:> FOLLOWUP & REPORT > > I had lots of suggestions, and the most persuasive was to try > OpenVPN. I already had a CA working, so issuing certificates was > easy. The HOW-TO guides were less helpful than I could hope, but > comparing several of them, applying common sense, and trying things > out, I arrived at a dead-end. Here's essentially what happened: > > - None of the HOW-TOs were very clear about the need to add some attributes > to a certificate, keyUsage and extendedKeyUsage. They had different values > for server and client. OpenSSL documentation was a big vague on how to add > them, but I think I did - the print out of the entity certificates showed the > values. The attempt to connect failed. The client log is below. I think > it's complaining that the CA certificate doesn't have the ke Usage extension, > which makes no sense to me. Such an extension should be in the end-entity > certificate, not the CA's, unless I'm wrong. I checked the server and really > think that the certificates are in the right place.Here's how I managed that in my openssl.cnf file. Lots of bits ellided for clarity's sake: ### start ### [ ca ] default_ca = CA_default [ CA_default ] x509_extensions = server_cert [ server_cert ] basicConstraints=CA:FALSE keyUsage = nonRepudiation, dataEncipherment, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, clientAuth nsCertType = server, client ### end ### I think the nsCertType directive may be unnecessary these days, but I keep it around because it doesn't hurt anything. The important bit is the extendedKeyUsage line; I'm pretty sure that an OpenVPN server needs the serverAuth extension. For instance, here is the X509 extensions configuration for a server used by EasyRSA: basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always extendedKeyUsage = serverAuth,clientAuth keyUsage = digitalSignature,keyEncipherment You can ask openssl to tell you the purpose of a certificate: [bash]$ openssl x509 -noout -purpose -in cert.pem | grep SSL SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No Anyway, those are the extensions that should do away with these errors:> Mon Apr 18 05:34:50 2016 VERIFY OK: depth=1, C=US, ST=California, L=San > Francisco, OU=Certificate Authority, O=XXXX, CN=X.X.X > Mon Apr 18 05:34:50 2016 Certificate does not have key usage extension-- Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/
At 09:09 AM 4/18/2016, you wrote:>On Mon, 18 Apr 2016, david wrote: > >>FOLLOWUP & REPORT >> >>I had lots of suggestions, and the most persuasive was to try >>OpenVPN. I already had a CA working, so issuing certificates was >>easy. The HOW-TO guides were less helpful than I could hope, but >>comparing several of them, applying common sense, and trying things >>out, I arrived at a dead-end. Here's essentially what happened: >> >>- None of the HOW-TOs were very clear about the need to add some >>attributes to a certificate, keyUsage and extendedKeyUsage. They >>had different values for server and client. OpenSSL documentation >>was a big vague on how to add them, but I think I did - the print >>out of the entity certificates showed the values. The attempt to >>connect failed. The client log is below. I think it's complaining >>that the CA certificate doesn't have the ke Usage extension, which >>makes no sense to me. Such an extension should be in the >>end-entity certificate, not the CA's, unless I'm wrong. I checked >>the server and really think that the certificates are in the right place. > >Here's how I managed that in my openssl.cnf file. Lots of bits >ellided for clarity's sake: > >### start ### >[ ca ] >default_ca = CA_default > >[ CA_default ] >x509_extensions = server_cert > >[ server_cert ] >basicConstraints=CA:FALSE >keyUsage = nonRepudiation, dataEncipherment, digitalSignature, keyEncipherment >extendedKeyUsage = serverAuth, clientAuth >nsCertType = server, client >### end ### > >I think the nsCertType directive may be unnecessary these days, but >I keep it around because it doesn't hurt anything. > >The important bit is the extendedKeyUsage line; I'm pretty sure that >an OpenVPN server needs the serverAuth extension. For instance, here >is the X509 extensions configuration for a server used by EasyRSA: > > basicConstraints = CA:FALSE > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid,issuer:always > extendedKeyUsage = serverAuth,clientAuth > keyUsage = digitalSignature,keyEncipherment > >You can ask openssl to tell you the purpose of a certificate: > >[bash]$ openssl x509 -noout -purpose -in cert.pem | grep SSL >SSL client : Yes >SSL client CA : No >SSL server : Yes >SSL server CA : No >Netscape SSL server : Yes >Netscape SSL server CA : No > >Anyway, those are the extensions that should do away with these errors: > >>Mon Apr 18 05:34:50 2016 VERIFY OK: depth=1, C=US, ST=California, >>L=San Francisco, OU=Certificate Authority, O=XXXX, CN=X.X.X >>Mon Apr 18 05:34:50 2016 Certificate does not have key usage extension > >-- >Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/Paul Two things... First, the diagnostic I got referenced the server's CA certificate. And that confuses me. Second, when I look server's purpose, using the openssl x509 -purpose command, I get: SSL client : No SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No When looking at the CLIENT's purpose, I get SSL client : Yes SSL client CA : No SSL server : No SSL server CA : No Netscape SSL server : No Netscape SSL server CA : No The difference between what I have and what you reported is that I've got SSL Client NO on the server, and SSL server NO on the client, which makes sense to me. The CA certificate itself, says: Certificate purposes: SSL client : Yes SSL client CA : Yes SSL server : Yes SSL server CA : Yes Netscape SSL server : Yes Netscape SSL server CA : Yes S/MIME signing : Yes S/MIME signing CA : Yes S/MIME encryption : Yes S/MIME encryption CA : Yes CRL signing : Yes CRL signing CA : Yes Any Purpose : Yes Any Purpose CA : Yes OCSP helper : Yes OCSP helper CA : Yes Time Stamp signing : No Time Stamp signing CA : Yes Advice would be appreciated. David