It would appear that the client you were inst5alling on did not support SHA256 - what version of OpenSSL does your version of OpenVPN include? Typically this can be a problem for what ever clients will use these certs e.g. M$ only just added SHA256 support to XP in a recent update NIST made a recommendation that folks move to SHA256 asap after some potential vulnerabilities were discovered in SHA1 - it just takes a while to get all platforms moved up... Regards, _Scott
John A. Sullivan III wrote: > On Tue, 2008-12-23 at 08:23 -0500, John A. Sullivan III wrote: > >> On Tue, 2008-12-23 at 07:59 -0500, John A. Sullivan III wrote: >> >>> On Tue, 2008-12-23 at 07:55 -0500, John A. Sullivan III wrote: >>> >>>> Hello, all. We're in a bit of a panic here this morning. After working >>>> through various issues, we were delighted to be ready to move OpenCA >>>> 1.0.2 into production. However, in this morning's testing, we found the >>>> PKCS#12 packages we issued for use with OpenVPN failing. >>>> >>>> The error from OpenVPN is: >>>> TLS_ERROR: BIO read tls_read_plaintext error: error:04067069:rsa >>>> routines:RSA_EAY_PUBLIC_DECRYPT:pkcs1 padding too short >>>> >>>> >From the little we've been able to find, this could be a key length >>>> error. In version 0.9.2, we simply told it to use a key length of 1024. >>>> In 1.0.2, I gather that is now a function of the combination of LOA and >>>> key strength. We chose Low and Base assuming that gave us a 1024 key. >>>> When we check the key, it claims to be 1024. The 0.9.2 packages are >>>> working just fine. Any idea what changed and how to fix it? Thanks - >>>> John >>>> >>> I should mention we are using server side key generation - John >>> >> We've tried using low and weak (512 bits), medium and base (1024 bits). >> All failed the same way. We also tried removing the subjalt entries. >> >> In 0.9.2, we typically chose a Basic Request. This option is no longer >> available in 1.0.2 so we have been choosing Browser Certificate Request >> and changing it to server side key generation. Would this cause a >> problem like this? Thanks - John >> > Well . . . we've solved the acute problem but do not really know what we > have stepped into. The fix was to edit the > etc/openca/openssl/openssl/User.conf.template and change default_md from > sha256 to sha1. We first did this on the pub node but it did not solve > the problem. It worked when we changed it on the RA node. We have not > taken the time to figure out if it needed to be both or just the RA. > > However, this leaves us with several serious questions: > > 1) Why was sha256 a problem? > 2) Is this a problem for more than just user packages, e.g., VPN > servers, Web servers? > 3) Whose problem is this? Is it a bad choice of defaults on the part of > OpenCA and thus should be treated as an OpenCA bug or is this a > shortcoming with OpenVPN? > > Can anyone offer any insight into what has happened and how we have > fixed it? Thanks - John > -- Scott Rea Director, HEBCA|USHER Operating Authority Dartmouth Senior PKI Architect Peter Kiewit Computing Services Dartmouth College HB 6238, #058 Sudikoff Hanover, NH 03755 Em: scott....@dartmouth.edu Ph#(603) 646-0968 Ot#(603) 646-9181 Ce#(603) 252-7339 ------------------------------------------------------------------------------ _______________________________________________ Openca-Users mailing list Openca-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openca-users
