Hi Victor,
A... that is why :D I wrongly assumed that the newly created
parameters would hold the same initialization. This approach works!
Thanks again!
Cheers,
Max
On 12/11/17 5:45 PM, Viktor Dukhovni wrote:
On Dec 11, 2017, at 7:35 PM, Dr. Pala wrote:
Perhaps you ended up creati
> On Dec 11, 2017, at 7:41 PM, Dr. Pala wrote:
>
> Does it matter that we are not in the TLS case?
No, the issue is not TLS-specific.
> IMHO, the correct (or, better, the expected) behavior (from a developer's
> standpoint) would be to trust keys in the trusted certificates list, no
> matte
> On Dec 11, 2017, at 7:35 PM, Dr. Pala wrote:
>
>> Perhaps you ended up creating a parameter structure with a
>> depth limit that's too small. Just configuring partial
>> chains will never yield a chain that is longer than it
>> otherwise would be. In fact you generally get shorter
>> chains
Hi Victor,
does it matter that we are not in the TLS case (maybe the code is
different in the SSL_CTX ) ? I am just trying to validate the chain with
the TA set to the SubCA... :D
IMHO, the correct (or, better, the expected) behavior (from a
developer's standpoint) would be to trust keys in
Hi Victor,
On 12/11/17 4:18 PM, Viktor Dukhovni wrote:
[...]
Perhaps you ended up creating a parameter structure with a
depth limit that's too small. Just configuring partial
chains will never yield a chain that is longer than it
otherwise would be. In fact you generally get shorter
chains.
> On Dec 11, 2017, at 6:27 PM, Michael Richardson wrote:
>
> I believe that I ran into a similar problem where by I could not pin
> ('trust') an intermediate certificate (which was not self-signed) for the
> purposes of verifying a CMS/PKCS7 object.
>
> I don't have a solution, and I believe t
> On Dec 11, 2017, at 6:20 PM, J Decker wrote:
>
> I'm pretty sure you need the root also, not just the intermedia ca...
The purpose of X509_V_FLAG_PARTIAL_CHAIN is to make it possible
to make do with just the intermediate certificate in the trust
store. So, no, the root is not always require
I believe that I ran into a similar problem where by I could not pin
('trust') an intermediate certificate (which was not self-signed) for the
purposes of verifying a CMS/PKCS7 object.
I don't have a solution, and I believe that work is required.
Dr. Pala wrote:
> I am trying to verify a ce
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 fro
> On Dec 11, 2017, at 6:03 PM, Dr. Pala wrote:
>
> 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 th
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 co
> On Dec 11, 2017, at 5:06 PM, Dr. Pala 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
> cert
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
usua
13 matches
Mail list logo
