This is not a check of the intermediate certificate as an actual
intermediate in a chain, this only checks it as a leaf certificate.
Your entire chain is just:
root ---> revokedIntermediate
Yes - as a leaf of root, using the roots crl to see if any root-signed certs
are revoked.
Try:
I am a bit wary that someone started adding certificates to the trust
store based on this new behavior not realizing that some is using it
with a different semantic. Maybe a note ("other software may not do the
same") would be appropiate.
I can't find the entry for this in CHANGES, though.
PS:
On Fri, Mar 11, 2016 at 10:38:19AM +0100, mihe...@gmx.de wrote:
> In further tracking down the cause i was trying to use "openssl verify"
> commands.
> When I issue the "openssl verify -CApath verifydir -crl_check
> revokedIntermediate.crt" the intermediate cert is correctly shown as
> revoked, so
>I am testing with revoking certificates.
>
>My PKI has a root and 2 intermediates, which then sign server and
client certificates
>My test environment consists of a s_client and a s_server referencing
the corresponding files and a verifydir with c_rehased files.
>TLS connections work fine from
On Fri, Mar 11, 2016 at 06:16:45AM +0100, Jakob Bohm wrote:
> >They are not trust-anchors, so absent an issuer higher up, they
> >are not sufficient to establish a "chain of trust", unless the
> >application enables "partial chain" support.
>
> Ok, that reverses the fundamental assumption behind a
On 11/03/2016 03:27, Viktor Dukhovni wrote:
On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:
Well, no, 1.0.2 uses the trust store not only for trust-anchors,
but also as a capricious source of intermediate certificates, whose
behaviour varies depending on whether the peer supplied sa
On Thu, Mar 10, 2016 at 11:14:12PM -0500, Jeffrey Walton wrote:
> > However, in 1.0.x (more bug than feature) basic constraints, key
> > usage constraints and EKU constraints, which are applied to
> > intermediate certificates provided by the peer, are not applied
> > when the intermediate certifi
>> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
>> >but also as a capricious source of intermediate certificates, whose
>> >behaviour varies depending on whether the peer supplied same said
>> >certificates on the wire or not. I expect to improve the capricious
>> >behaviour.
On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:
> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
> >but also as a capricious source of intermediate certificates, whose
> >behaviour varies depending on whether the peer supplied same said
> >certificates on the wire or
On 11/03/2016 02:23, Viktor Dukhovni wrote:
On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:
I am arguing that:
- 1.0.x behavior should not be changed, as it would violate the
principle of least surprise for a "security update" to change
semantics.
The odd 1.0.x behaviour l
On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:
> I am arguing that:
>
> - 1.0.x behavior should not be changed, as it would violate the
> principle of least surprise for a "security update" to change
> semantics.
The odd 1.0.x behaviour leads to periodic email to openssl-securi
On 11/03/2016 01:18, Viktor Dukhovni wrote:
On Fri, Mar 11, 2016 at 12:56:04AM +0100, Jakob Bohm wrote:
Your reply below is a perfect illustration of the expected confusion.
Sorry, I disagree. The 1.1.0 changes fix various shortcomings that
may well also be addressed in a future 1.0.2 update.
On Fri, Mar 11, 2016 at 12:56:04AM +0100, Jakob Bohm wrote:
> Your reply below is a perfect illustration of the expected confusion.
Sorry, I disagree. The 1.1.0 changes fix various shortcomings that
may well also be addressed in a future 1.0.2 update.
The net effect is more consistent behaviour
On 10/03/2016 23:41, Viktor Dukhovni wrote:
On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:
This is changing in OpenSSL 1.1.0, and may yet change in a future
OpenSSL 1.0.2 update. Only the trust-anchor (top-most certificate
>from the trust-store) is not checked for expiration or r
On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:
> >This is changing in OpenSSL 1.1.0, and may yet change in a future
> >OpenSSL 1.0.2 update. Only the trust-anchor (top-most certificate
> >from the trust-store) is not checked for expiration or revocation
> >in OpenSSL 1.1.0.
> >
> >In
On 10/03/2016 23:06, Viktor Dukhovni wrote:
On Thu, Mar 10, 2016 at 10:41:28PM +0100, Jakob Bohm wrote:
Any ideas what i could be doing wrong?
Make sure the intermediary is not included in the "CA storage"
(hashed or single file) used by the client. Anything in that
storage is considered vali
On Thu, Mar 10, 2016 at 10:41:28PM +0100, Jakob Bohm wrote:
> >Any ideas what i could be doing wrong?
>
> Make sure the intermediary is not included in the "CA storage"
> (hashed or single file) used by the client. Anything in that
> storage is considered valid and not checked for revocation or
On 10/03/2016 20:11, mich...@secure-mail.biz wrote:
Hey openssl users,
I am testing with revoking certificates.
My PKI has a root and 2 intermediates, which then sign server and
client certificates
My test environment consists of a s_client and a s_server referencing
the corresponding files a
Hey openssl users,I am testing with revoking certificates.My PKI has a root and 2 intermediates, which then sign server and client certificatesMy test environment consists of a s_client and a s_server referencing the corresponding files and a verifydir with c_rehased files.TLS connections work fine
* Dr. Stephen Henson wrote on Wed, Sep 02, 2009 at 15:08 +0200:
> Including a public key certificate in no way risks the
> integrity of its private key as several others have said in
> this thread.
I think this theoretically opens the possibility to brute-force
the private key.
I think that Brute
* Serge Fonville wrote on Wed, Sep 02, 2009 at 13:00 +0200:
> The chain always includes all CAs and certificates. I've done some
> googling, and it shows that you can trust 'just' the intermediate CA
> without trusting the root CA, altough this kinda obsoletes the purpose
> of the root CA.
[...]
On Wed, Sep 02, 2009, Yin, Ben 1. (NSN - CN/Cheng Du) wrote:
> OK, regarding the CA deploy, such as, we have a one root ca and 1000 sub ca
> signed by root ca. and each sub ca used as ca by 1000 terminals.so the total
> network size is 1000*1000. All our ca, including root ca and sub ca, was
> sto
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 1:30 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certific
sl-us...@openssl.org]
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 1:30 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
If you are using client certificates, use a CRL at the server side.
that way you can assure that only those that you
t;
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 12:52 PM
> To: openssl-users@openssl.org
> Subject: Re:
eptember 02, 2009 12:52 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
Wat exactly are the applications you use, are they compiled against
openssl libraries?
On Wed, Sep 2, 2009 at 11:49 AM, Yin, Ben 1. (NSN - CN/Cheng
Du) wrote:
> Yes. When server send certifi
sl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> Everytime an application connects to an ssl-enabled server the
> certificate chain is verified.
>
> On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN/Cheng
> Du) wrote:
>> Hi,
>>
>
ext Serge Fonville
Sent: Wednesday, September 02, 2009 12:43 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
Everytime an application connects to an ssl-enabled server the
certificate chain is verified.
On Wed, Sep 2, 2009 at 11:37 AM, Yin, Ben 1. (NSN - CN
11:59 AM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> If your client application supports that, it could be done. but no
> standard compliant application allows that to my knowledge.
>
> On Wed, Sep 2, 2009 at 10:35 AM, Yin, Ben 1
g]
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 11:59 AM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
If your client application supports that, it could be done. but no
standard compliant application allows that to my knowledge.
On Wed,
enssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Wednesday, September 02, 2009 11:28 AM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> How do you think compromising a CA would occur, because a CA could
> only becom compro
sl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of ext Serge Fonville
Sent: Wednesday, September 02, 2009 11:28 AM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
How do you think compromising a CA would occur, because a CA could
only
rg] On Behalf Of ext Serge Fonville
> Sent: Tuesday, September 01, 2009 5:14 PM
> To: openssl-users@openssl.org
> Subject: Re: Verify certificate using subordinate ca
>
> I don't see your problem honestly. Figuring out a private key is close
> to impossible.
> And stealing
enssl-us...@openssl.org]
On Behalf Of ext Serge Fonville
Sent: Tuesday, September 01, 2009 5:14 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
I don't see your problem honestly. Figuring out a private key is close
to impossible.
And stealing it, well, th
to fix the our whole network. Thanks.
>
>
> Br
>
> Ben
>
> -Original Message-
> From: owner-openssl-us...@openssl.org
> [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville
> Sent: Tuesday, September 01, 2009 4:31 PM
> To: openssl-users@
ptember 01, 2009 4:31 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
Based on what you state.
There is no purpose for the root CA.
What do you mean by compromised.
If you publish a CA certificate to clients, it does not include the
key. (normally)
So the on
@openssl.org] On Behalf Of ext Yin, Ben 1.
> (NSN - CN/Cheng Du)
> Sent: Tuesday, September 01, 2009 3:06 PM
> To: openssl-users@openssl.org
> Subject: RE: Verify certificate using subordinate ca
>
> Hi Serge,
>
> My intention is to keep my root ca out of compromise. We want to
Hi,
It there a way to verify certificate with out root ca? I have 4
certificate: rootca.pem is the root ca (self signed). subca.pem was
signed by rootca.pem. cert1.pem & cert2.pem was signed by subca.pem. I
was supposed to configure the client and server using subca.pem as ca,
and cert1.pem & cert
Ben
-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Yin, Ben 1.
(NSN - CN/Cheng Du)
Sent: Tuesday, September 01, 2009 3:06 PM
To: openssl-users@openssl.org
Subject: RE: Verify certificate using subordinate ca
Hi Serge,
My intenti
e Fonville
Sent: Tuesday, September 01, 2009 2:14 PM
To: openssl-users@openssl.org
Subject: Re: Verify certificate using subordinate ca
Hi,
Hmm...
I've had the same issue.
Basically it came down to "how do you know if the sub is reliable if
you do not know whether to trust the root?"
Hi,
Hmm...
I've had the same issue.
Basically it came down to "how do you know if the sub is reliable if
you do not know whether to trust the root?"
If you do not wish to have the root as part of the chain, create a new
chain where the sub is the root
What is the reason you do not want to use the
> Hi,
>
> It there a way to verify certificate with out root ca? I have 4
> certificate: rootca.pem is the root ca (self signed). subca.pem was
> signed by rootca.pem. cert1.pem & cert2.pem was signed by subca.pem. I
> was supposed to configure the client and server using subca.pem as ca,
> and ce
I've setup an openssl root and a subordinate CA. I have successfully
signed CA certificate for the subordinate from the root (used the
-newreq option), however when I execute the 'ca.pl -newca' it doesn't
set up the subordinate authority at all. When it asks for the CA
cer
Does anyone have a step-by-step guide for getting an OpenSSL root
authority and a Microsoft Issuing CA working? I have it working to the
point of getting the root and issuing CA created, but when I try to
issue web server certificates, it doesn't work. Further research
revealed that it was becaus
Hello,
I am using OpenSSL to implement SSL in my application, I would
like to enable trusting subordinate CA in my server (I do not want to trust the
root CA and other subordinate CA’s, only a specific subordinate CA), I
have used the verify callback and I can do this, but I have
ut cacert.pem -outform PEM -config openssl.cnf
>
> On box 2 Subordinate CA:
> openssl req -newkey rsa:2048 -days 2190 \
> -out cacert.pem -outform PEM -config openssl.cnf
> I try to sign the subordinate CA with the main ca like this:
> On box1 in the main CA directory:
> o
I am trying to create a hirearchy for my CA's...however when I have two
separate CA's created similarly:
On box 1 Main CA:
openssl req -newkey rsa:2048 -days 4380 \
-out cacert.pem -outform PEM -config openssl.cnf
On box 2 Subordinate CA:
openssl req -newkey rsa:2048 -days 2190 \
-out
Let me summarize his report:
I fooled the test root CA into signing a cert with the cert-sign bit.
I betcha this works with the production CA."
Let me respond:
I betcha it doesn't work.
__
OpenSSL Project
Message-
From: Pidgorny, Slav [mailto:[EMAIL PROTECTED]]
Sent: Sunday, 19 May 2002 6:01
To: '[EMAIL PROTECTED]'
Subject: Verisign PKI: anyone to subordinate CA
G'day Bugtraq,
Microsoft Security Bulletin MS01-017
(http://www.microsoft.com/technet/security/bulletin/MS01-017.as
res Aguilar
- Original Message -
From: "Dr S N Henson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 18, 2001 5:32 PM
Subject: Re: subordinate CA
> Juan Carlos Albores Aguilar wrote:
> >
> > thanks for the tip but CA.pl it doesn
> chgu wrote:
>
> Hi,
>
> I have created a root CA using openssl. And it can sign server/user
> certificate(s) normally. Now i want to sign a subordinate root CA
> certificate. But i don't know how to do it and what configuration
> files
> need. Can you help
51 matches
Mail list logo
