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/