Hi, On 19/04/16 16:12, Lionel Elie Mamane wrote: > On Tue, Apr 19, 2016 at 06:46:27AM -0400, Colin Ryan wrote: > >> I'm fairly certain you need the full cert path, including root and >> any intermediate certs. >> To not require this would question the whole point of the cert's. >> I don't, to be frank, understand why you want to not have the rootCA >> included. > Because if I include it, OpenVPN will accept certificates signed by > rootCA. I don't want that. > > I run like that with e.g. Firefox. It correctly accepts certificates > signed the subCA known to it, but refuses anything signed by the > rootCA (or another subCA). > > Also note that something like: > > openssl verify -CAfile /path/to/vpnSubCA.pem -purpose sslserver -verbose > -x509_strict server.crt > > gives an "OK" result. > >> The server - correct me if I'm wrong - would only need the >> private key of the subCA and the vpnCert's so it not that you need to >> have your CA. private key in a place you wouldn't want it. > The server needs only the private key of its own certificate, > e.g. vpnCertificat1, not of any CA. I need OpenVPN to not trust > rootCA, only trust vpnSubCA. > >> On 2016-04-19 1:41 AM, Lionel Elie Mamane wrote: >>> Hi, >>> >>> I run my own private CA with a structure like: >>> >>> rootCA ---- vpnSubCA >>> | |-------- vpnCertificate1 >>> | |-------- vpnCertificate2 >>> | |-------- vpnCertificate3 >>> | >>> |---- otherCertificate1 >>> |---- otherCertificate2 >>> |---- otherCertificate3 >>> |---- otherCertificate4 >>> >>> >>> I need OpenVPN to accept (for verify-x509-name and ccid-exclusive) >>> only certificates signed by vpnSubCA, *not* any certificate signed >>> directly by "root CA" nor by any other sub-CA of rootCA. >>> >>> >>> But when I try to do that, I get on the client side an error like: >>> >>> VERIFY ERROR: depth=1, error=unable to get local issuer certificate: >>> SUBJECT_OF_vpnSubCA >>> >>> Here's how I try to do that: >>> On the client *and* the server, I put in the configuration file >>> ca /etc/ssl/certs/vpnSubCA.pem >>> >>> >>> I successfully got OpenVPN to work with: >>> >>> * On the client >>> ca /etc/ssl/certs/rootCA.pem >>> >>> * On the server >>> ca file_with_rootCA_and_vpnSubCA_concatenated >>> >>> But that does not do what I want. >>> >>> I'm using OpenVPN 2.3.4 (Debian package). >>> >>> Thanks in advance for any help,
the "proper" way to do this is to use - do a full CA+sub CA check on the server side (i.e. stack ca.crt + subca.crt into a single file and use it as "ca ..." ) - add a "tls-verify" script to ensure that the certificate chain always ends with the subCA signed by the CA. The "tls-verify" script is called for each certificate in the stack, e.g. 17:47:16: START tls-verify script === argv = check-ca.sh 2 C=US, O=Cookbook 2.4, CN=Cookbook 2.4 CA, emailAddress=open...@example.com X509_2_C=US X509_2_emailAddress=open...@example.com X509_2_O=Cookbook 2.4 X509_2_CN=Cookbook 2.4 CA 17:47:17: END tls-verify script === 17:47:17: START tls-verify script === argv = check-ca.sh 1 C=US, O=Cookbook 2.4, CN=subCA, emailAddress=open...@example.com X509_1_emailAddress=open...@example.com X509_1_O=Cookbook 2.4 X509_1_C=US X509_2_C=US X509_2_emailAddress=open...@example.com X509_2_O=Cookbook 2.4 X509_1_CN=subCA X509_2_CN=Cookbook 2.4 CA 17:47:17: END tls-verify script === 17:47:17: START tls-verify script === argv = check-ca.sh 0 C=US, O=Cookbook 2.4, CN=clientS1 X509_1_emailAddress=open...@example.com X509_1_O=Cookbook 2.4 X509_0_CN=clientS1 X509_1_C=US X509_2_C=US X509_2_emailAddress=open...@example.com X509_2_O=Cookbook 2.4 X509_1_CN=subCA X509_0_C=US X509_0_O=Cookbook 2.4 X509_2_CN=Cookbook 2.4 CA 17:47:17: END tls-verify script === The first invocation is for the CA itself (argv1=2, argv2=DN-of=CA); the second invocation is to check the sub-CA (argv1=1, argv2=DN-of-sub-CA). The final invocation is for the client's certificate. I'd simply add a check for (argv1=1) that the supplied DN is that of the sub-CA (vpnSubCA in your case) and reject all others. Alternatively you could walk the entire chain (see the available env vars above) , but that would only complicate things, IMHO. HTH, JJK ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
