Re: Trust *only* certs signed by intermediate CA
Create a new self-signed client CA certificate with the same key and Subject, setting the Issuer to the Subject of the client CA, and signed with the client CA private key. Use this as your client-authenticatior root. Alternatively, you might play around with policies, but that relies on your hierarchy already having policies in its certificates. -Kyle H On Mar 8, 2013 3:18 PM, Ian Pilcher arequip...@gmail.com wrote: +-+ | Root CA | +-+ /\ / \ /\ / \ /\ / \ /\ / \ +---++---+ | Server CA || Client CA | +---++---+ Given the above CA hierarchy, how can I configure a (server) SSL_CTX to accept connections *only* from clients which present a certificate signed by the Client CA? As is well documented, I cannot simply trust the Client CA. SSL_accept() will fail, because it cannot form a certificate chain all the way to the self-signed Root CA. I have found, however, that adding the Root CA certificate to the trusted certificate file/directory causes certificates signed by the Server CA to be accepted as well. (The client has to present both its certificate and the Server CA certificate, but it is able to connect.) So how can I do this? Thanks! -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Extra bytes before the decrypted data.
On Fri, Mar 08, 2013, Tayade, Nilesh wrote: Hi, On performing the AES128 decryption, I see the decrypted data is preceded by a block of 16bytes. E.g. Below, 0x48 to 0x5a is the extra 16bytes block. And the actual 'GET' request starts from 0x47 onwards. 48 3f c4 99 fa f0 75 0e 51 b8 3b 58 aa 1f 4a 5a 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a ... 5b 28 c4 52 4e f9 53 2c 08 04 94 04 04 04 04 04 There is a padding of 5bytes in the end, which I can detect. Any pointers on how to detect the initial 16bytes block? This causes the output to be some junk followed by actual data. I cannot use EVP* APIs for some reason, so I am using the low level aes_cbc_encrypt() function. Any pointers will be appreciated. You don't say *what* you are decrypting but from the look of it is a TLS record. The padding for TLS records is not standard block padding so you have to disable that if you use the EVP interface and remove it manually. Considerable care is needed when removing the padding to avoid security issues: see the recent discussion for CVE-2013-0169. As others have pointed out the first block is the IV that applies to TLS 1.1 and later or all versions of DTLS. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Trust *only* certs signed by intermediate CA
On 03/09/2013 10:40 AM, Kyle Hamilton wrote: Create a new self-signed client CA certificate with the same key and Subject, setting the Issuer to the Subject of the client CA, and signed with the client CA private key. Use this as your client-authenticatior root. Well yes. I know I could workaround this by creating a self-signed root for the clients. The point of the question is how to do this with a hierarchy like the one I've described. It's becoming pretty clear that OpenSSL doesn't provide a simple way to do this today. (X509_V_FLAG_PARTIAL_CHAIN will probably enable this, but it will be years before that makes its way into slower moving distributions.) Alternatively, you might play around with policies, but that relies on your hierarchy already having policies in its certificates. My current thinking is that I should be able to do it with a validation callback. I haven't worked out the details yet. -- Ian Pilcher arequip...@gmail.com Sometimes there's nothing left to do but crash and burn...or die trying. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Trust *only* certs signed by intermediate CA
On Sat, Mar 09, 2013 at 11:04:06AM -0600, Ian Pilcher wrote: It's becoming pretty clear that OpenSSL doesn't provide a simple way to do this today. (X509_V_FLAG_PARTIAL_CHAIN will probably enable this, but it will be years before that makes its way into slower moving distributions.) Alternatively, you might play around with policies, but that relies on your hierarchy already having policies in its certificates. My current thinking is that I should be able to do it with a validation callback. I haven't worked out the details yet. Yes, SSL_CTX_set_verify() or SSL_set_verify() allow you to validate the trust chain yourself. Note: Contrary to documentation the callback order is not necessarily from the root down to the leaf in a single pass, rather this is only the final list of callbacks. Prior callbacks may report other issues in some other order (only error reports, never with ok=1). Thus you may need to keep some state which you evaluate each time the callback is made at depth 0. By final depth 0 call you'll have all the required information and will be able to allow or reject the connection (or just update its verification status without failing the handshake). This is the approach taken in the Postfix DANE implementation (under development). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
