I'm pretty sure you need the root also, not just the intermedia ca... I use a custom generated chain... I encode the root cert in the application, and then pass it when inintializing the client socket.
This bit of code takes the root cert and adds it to the SSL_CTX the client socket is created from.... https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L704 ( if no root passed, it loads root certs from windows store; haven't finished linux load cert store) THis is where the cert chain is verified.... https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L264 looking at that, I guess I should split that if and fail if it fails to get the peer certificate... On Mon, Dec 11, 2017 at 3:03 PM, Dr. Pala <madw...@openca.org> wrote: > Hi Victor, > > thanks :D I just tried to set it and I get a different error now : 22 > (certificate chain too long)... I suspect it is a side effect of using the > X509_V_FLAG_PARTIAL_CHAIN flag... ? (no chain restrictions are set in the > certificates themselves...), but I have not dug into the vfy code yet... > > ... any suggestion on how to fix this ? Do you think it is actually a bug > ? ... or am I missing some other configs / setting I should have done for > the verify param ? > > Cheers, > Max > > > On 12/11/17 3:18 PM, Viktor Dukhovni wrote: > >> >> On Dec 11, 2017, at 5:06 PM, Dr. Pala <direc...@openca.org> wrote: >>> >>> Hi all, >>> >>> I am trying to verify a certificate and provide the possibility to >>> directly trust an intermediate CA's certificate (not self-signed). After >>> setting up the STORE and STORE_CTX and add the intermediate CA to the >>> trusted certificates, when I use the "X509_verify_cert(ctx)" I get the >>> usual "unable to get issuer certificate" - which would be fine for a >>> "non-trusted" cert, but I would expect that to not be an issue for a >>> trusted certificate. >>> >>> Therefore, my question is what is the best method to have that behavior ? >>> >>> I tried to use the certificate callback to do that, but there is no >>> function to get the trusted certificates' stack (i.e., there is a >>> X509_STORE_CTX_get0_untrusted() but there is no equivalent for the >>> trusted certificates' stack) - so I could not verify if the current >>> certificate (in the verify callback call) is in the trusted stack or not... >>> >>> Maybe there are flags / trust settings that can be used instead ? >>> >> It seems we've neglected to document the X509_V_FLAG_PARTIAL_CHAIN >> flag, which can be passed to X509_VERIFY_PARAM_set_flags() to >> permit intermediate trust-anchors. >> >> https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PAR >> AM_set_flags.html >> https://www.openssl.org/docs/man1.1.0/crypto/X509_VERIFY_PAR >> AM_set_flags.html >> >> >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
