> And we don't know on which client OP will have to use that pem file, thus
> give advise that works on all clients, not just OpenSSL or GnuTLS or whatever.
It is quite reasonable to give openssl-specific answers on the openssl-users
mailing list, isn’t it?
__
2015-12-13 20:27 GMT+01:00 Viktor Dukhovni :
>
> This is both wrong and irrelevant. The OP should proceed as instructed.
> OpenSSL's CAfile feature reads multiple certificates from a single file.
Exactly that is the point. Only "linux based" tools will be able to
read such a pem file. Windows cer
Thanks Erwann,
I appreciate your point regarding the cost of a signing operation. I plan
to take action on this. Pointing out RFC 5280 in regards to what status it
will return when it fails to download a fresh CRL helped a lot. I now see
that revoked is not "a" correct response according to the l
> On Dec 13, 2015, at 5:34 AM, Ben Humpert wrote:
>
> 2015-12-13 3:53 GMT+01:00 Viktor Dukhovni :
>>
>> In other words, you can concatenate all the trusted root CA
>> certs into the "cert.pem" file in that directory, but this
>> has a performance cost, as all the certificates are loaded
>> into
Hi All,
Thanks for all the responses. As mentioned by Matt in the discussion
thread,constant_time_msb performs the copy the msb of the input to all of
the other bits so the return value should either be one of 0x or
0x.
I found another interesting thing,constant_time_msb worke
On 13.12.2015 11:34, Ben Humpert wrote:
2015-12-13 3:53 GMT+01:00 Viktor Dukhovni:
In other words, you can concatenate all the trusted root CA
certs into the "cert.pem" file in that directory, but this
has a performance cost, as all the certificates are loaded
into memory and parse even though m
2015-12-13 3:53 GMT+01:00 Viktor Dukhovni :
>
> In other words, you can concatenate all the trusted root CA
> certs into the "cert.pem" file in that directory, but this
> has a performance cost, as all the certificates are loaded
> into memory and parse even though most go unused. Alternatively,
