>Or is that an attacker wouldn't be able to figure out how to format the
parameters?
Bingo. Nor will he know valid values for those parameters.
If someone goes to the trouble to run the app in an environment where he can
scrutinize memory contents, then he can figure all this out. But that's
bey
On 5/18/2011 3:27 AM, G S wrote:
I'm probably being obtuse here, but I don't see how encrypting your
request with a public key would help you with your original problem.
What stops a rogue app from doing the same encryption?
They can't see what the parameters are. So what are they
Hi Erwann!
On 05/19/2011 10:20 AM, Erwann ABALEA wrote:
"old" end-user certificates can only be verified by the "old" CA
certificate, of course (in case the CA is "renewed", with its key
changed, etc).
I didn't "renew" the CA certificate, I've used the existing private key
to create thr new o
Hi Erwann!
On 05/19/2011 10:20 AM, Erwann ABALEA wrote:
"old" end-user certificates can only be verified by the "old" CA
certificate, of course (in case the CA is "renewed", with its key
changed, etc).
I didn't "renew" the CA certificate, I've used the existing private key
to create thr new
Serial Number/Randomness apart;
how many certificates would you expect to issue in a year?
How would you deploy the cert for trust among the different browsers?
You should ensure that your certificates for SSL usage specify the appropriate
EKU OID, in addition to path and issuance restricti
Hodie XIV Kal. Iun. MMXI, Dave Thompson scripsit:
> > From: owner-openssl-us...@openssl.org On Behalf Of Erwann ABALEA
> > Sent: Thursday, 19 May, 2011 04:20
>
> > Hodie XV Kal. Iun. MMXI, Alex Bergmann scripsit:
>
> > > The only way I found was to give the new Root Certificate the same
> > > ser
