Hi,
I'm actually testing this with openssl 1.0.1, which explains the
behavior. I misunderstood what you where saying about openssl 1.0.1
being not clever.
Looks like I'll have to wait for openssl 1.0.2 being rolled out to all
my clients, or do a hard transition to the new CA, meaning some
Hi,
Dave, thank you very much for your suggestions. This sounds like the
solution I'm looking for. I've set up a completely new PKI to test this,
but I'm still having one problem.
What I did was:
- I generated a newRootCA (new keypair, selfsigned certificate).
- I generated another selfsigned
From: owner-openssl-us...@openssl.org On Behalf Of Sven Reissmann
Sent: Thursday, May 29, 2014 12:24
snip
What I did was:
- I generated a newRootCA (new keypair, selfsigned certificate).
- I generated another selfsigned certificate (bridgeCert) from the
newRootCA's private key. From
Hello,
On Tue, May 27, 2014 15:44, Sven Reissmann wrote:
Hi,
I'm having a comprehension question on certificate verification.
Having a trustchain like this:
rootCA - subCA - subCA2
I can verify the subCA2 certificate using the command:
openssl verify -CAfile rootCA.pem -untrusted
On Tue, May 27, 2014 at 03:44:46PM +0200, Sven Reissmann wrote:
But, should't it also be possible to only verify the trust chain up to
the subCA (i.e., if I fully trust this CA)? I would have expected that
this will verify sucessfully:
OpenSSL versions prior to 1.0.2 require that all trusted
On Tue, May 27, 2014, Viktor Dukhovni wrote:
On Tue, May 27, 2014 at 03:44:46PM +0200, Sven Reissmann wrote:
But, should't it also be possible to only verify the trust chain up to
the subCA (i.e., if I fully trust this CA)? I would have expected that
this will verify sucessfully:
Hi,
thank you all for the clarification. As most users do not have OpenSSL
1.0.2, this doesn't seem to solve my problem.
What I want to achieve is having a new rootCA, which replaces an
oldRootCA, which I am using until now.
So far the trust chain is: oldRoot - oldServerCert.
What I thought
Hi Sven,
-Original Message-
From: Sven Reissmann
What I want to achieve is having a new rootCA, which replaces an
oldRootCA, which I am using until now.
So far the trust chain is: oldRoot - oldServerCert.
What I thought should be possible is building this trust chain:
oldRoot
The X.509-canonical way to do this is to have the old trust anchor sign a
new certificate containing the new public key, using the same Issuer name
and a different AuthorityKeyIdentifier. This is called key rollover, but
it retains the security level of the old key (meaning, if the original
trust
From: owner-openssl-us...@openssl.org On Behalf Of Eisenacher, Patrick
Sent: Tuesday, May 27, 2014 12:41
From: Sven Reissmann
What I want to achieve is having a new rootCA, which replaces an
oldRootCA, which I am using until now.
So far the trust chain is: oldRoot - oldServerCert.
I've being using the OpenTSA software under apache2 on solaris in order to mimic other RFC3163 compliant Time Stamp Servers and work this in with software I'm in the process of writing.
One of the commercial providers we are looking at using is Digistamp. They differ in the way that they issuer
CA.
With TSAESSCertIdChain set to Off, the verify works.
Brad
_
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of
bradmrem...@iinet.net.au
Sent: Wednesday, December 17, 2008 10:18 AM
To: openssl-users@openssl.org
Subject: Re: verification
12 matches
Mail list logo
