At 08:57 AM 4/19/2016, you wrote:
On Tue, 19 Apr 2016, david wrote:
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@xxxxxxxxxx <> http://www.madboa.com/
Paul
Two things...
First, the diagnostic I got referenced the server's CA certificate.
And that confuses me.
I'm not sure that's actually what the log is indicating. I think
there's a mismatch between what extensions the server certificate
says it can provide and what the client is expecting.
Can you provide the SSL/TLS parts of your client configuration?
In particular, I expect you'll have a "remote-cert-tls server"
directive. I'd suggest commenting that out (or replacing it with
"ns-cert-type server") and trying again.
If that succeeds, you'll probably need to review your CA configuration.
--
Paul
I'm not sure what you mean by the SSL/TLS parts of client
configuration. Here's what I have for openvpn
Configuration files... comment lines removed
The client file at
c:\program files\OpenVPN\config\client.opvn
----------------------------
client
dev tun
remote X.X.X 1194
resolv-retry infinite
persist-key
persist-tun
ca "C:\\Program Files\\OpenVPN\\config\\bla.ca"
cert "C:\\Program Files\\OpenVPN\\config\\bla.crt"
key "C:\\Program Files\\OpenVPN\\config\\bla.key"
remote-cert-tls server
comp-lzo
verb 3
----------------------------------------
The Server file at
/etc/openvpn/openvpn-server.conf
---------------------------------------------
ca /etc/pki/tls/certs/ca-bundle.crt
cert /etc/pki/tls/certs/localhost.crt
client-to-client
dev tun
dh /etc/pki/tls/private/dh.pem
keepalive 10 120
key /etc/pki/tls/private/localhost.key
port 1194
proto tcp-server
push "dhcp-option DNS 192.168.155.2"
push "redirect-gateway def1 bypass-dhcp"
server 192.168.155.16 255.255.255.240
#log openvpn.log
verb 4
user nobody
group nobody
local a.b.c.d
---------------------------------------
David
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
