e
> > *SSL_CTX_set_cert_verify_callback* ?
>
> I rewrote the OpenSSL chain construction code for OpenSSL 1.1.0. Yes, I
> am sure.
>
> > - *build_chain* that will apply the trusted first algorithm and replace
> the
> > certificate chain passed by the server with the valid one
chain construction code for OpenSSL 1.1.0. Yes, I
am sure.
> - *build_chain* that will apply the trusted first algorithm and replace the
> certificate chain passed by the server with the valid one ( if found ).
The code in eventmachine does not configure any trusted certificates for
th
261>
The function *X509_verify_cert* calls *verify_chain(ctx)* line 295 which in
turns calls:
- *build_chain* that will apply the trusted first algorithm and replace the
certificate chain passed by the server with the valid one ( if found ). At
the point the ctx has the new chain
- *internal_ve
> On 3 Oct 2021, at 12:33 pm, Alex Robuchon
> wrote:
>
> So I suppose openssl skip the part that is supposed to build the chain when
> no store is configured.
Not quite, a candidate chain is constructed from whatever certificates
the peer (server in your case) provided, and then passed to the
I just had a big laugh Reading this. I never had to dig into openssl before
so I unfortunately had to try to understand your API with eventmachine as
an example. Silly me.
> On the other hand I suppose if we do not call this it would pick the
> "default" trust store from the system which seems to
On Sun, Oct 03, 2021 at 01:54:44PM +0200, Alex Robuchon wrote:
> Thanks for the detailed answer.
>
> From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1
>
> When I use the eventmachine lib that uses the wrong cert chain I can see
> with strace :
Run as far away from eventma
Thanks for the detailed answer.
>From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1
When I use the eventmachine lib that uses the wrong cert chain I can see
with strace :
openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat("/usr/l
On Sat, Oct 02, 2021 at 06:21:00PM +0100, Angus Robertson - Magenta Systems Ltd
wrote:
> > Yes. To make things even more complex, a few sites also have an
> > older version of R3 that is directly signed by the DST root:
> >
> > - leaf <- R3 <- DST Root CA X3 (self-signed)
> >
> > but tha
> Yes. To make things even more complex, a few sites also have an
> older version of R3 that is directly signed by the DST root:
>
> - leaf <- R3 <- DST Root CA X3 (self-signed)
>
> but that's far from common at this point.
That old R3 root was issued last winter and got installed in Wind
trust store) does not contain the ISRG root CA certificate
* The version of OpenSSL used (perhaps indirectly via some
library that is linked with an older OpenSSL) is 1.0.x
rather than 1.1.0 or later.
> From what I understood about the let's encrypt certificate chain,
a callback
function registered with SSL_CTX_set_verify and failed to verify DST Root
CA X3 since it expired.
>From what I understood about the let's encrypt certificate chain, R3 is
cross signed and two chained could be built:
- leaf <- R3 <- ISRG Root X1 <- DST Root CA X3 (self-sign
I apologize for bringing this old subject back up, but I'm running into
something I wanted to poll the list on.
Based on Victor's email below, I am doing the following in my application to
set up my server to send a certificate chain *excluding* the root certificate
during a handshak
> On May 31, 2019, at 3:20 PM, Jason Schultz wrote:
>
> My questions deal with #2: Why does OpenSSL include the root cert in the
> certificate chain?
The OpenSSL SSL_CTX_build_cert_chain(3) function constructs a complete
chain of trust for your certificate chain, based on the conf
ore importantly, can I force OpenSSL to not send the root cert?
Thanks,
Jason
From: Sam Roberts
Sent: Friday, May 31, 2019 7:32 PM
To: Jason Schultz
Cc: openssl-users@openssl.org
Subject: Re: OpenSSL server sending certificate chain(inc. root cert) during
hand
The root cert is not used for validation, so it doesn't have to be
sent. However, sending it does no harm, and it is useful for humans
who are attempting to diagnose problems, it allows them to see what
what root cert they are expected to have locally for sucessful cert
chain validation.
certs/,
the entire chain will be presented during the handshake.
My questions deal with #2: Why does OpenSSL include the root cert in the
certificate chain? Will the root cert be included in the chain any time it's in
the same directory as the server cert? Is there a way, via API call,
con
Yes it's only for testing so it doesn't matter.
But how do I do this?
2017-11-30 19:54 GMT+01:00 Viktor Dukhovni :
>
>
> > On Nov 30, 2017, at 2:46 AM, Pascal Withopf
> wrote:
> >
> > Here is serverCA.pem as a file and as text
>
> These are, I expect, test certs and keys, so posting the keys to
> On Nov 30, 2017, at 2:46 AM, Pascal Withopf wrote:
>
> Here is serverCA.pem as a file and as text
These are, I expect, test certs and keys, so posting the keys too
is presumably not a problem...
In any case, the problem is that the CA certificate is a v1
certificate with no extensions. It
Here is serverCA.pem as a file and as text
-BEGIN CERTIFICATE-
MIICJTCCAY4CCQCS+4ZH1+sfwzANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJY
WDELMAkGA1UECAwCWFgxDTALBgNVBAcMBHRlc3QxGTAXBgNVBAoMEFRlc3Rvcmdh
bmlzYXRpb24xEDAOBgNVBAMMB1Jvb3QgQ0EwHhcNMTcxMTMwMDczMDEzWhcNMTcx
MjMwMDczMDEzWjBYMQswCQYDVQQGEwJY
> On Nov 29, 2017, at 10:57 AM, Pascal Withopf wrote:
>
> $ openssl x509 -in serverCA.pem -noout -purpose
>
> ...
>
> If the purpose is incorrect how can I set it?
>
> 2017-11-29 16:48 GMT+01:00 Viktor Dukhovni :
> On Wed, Nov 29, 2017 at 04:33:39PM +0100, Pascal Withopf wrote:
>
>>> err 2
:33:39PM +0100, Pascal Withopf wrote:
>
> > Which means I have the following certificate chain:
> > root.pem -> serverCA.pem -> server.pem
> >
> > But when I try to make a connection I see following error at the client
> > side:
> > Error with certificat
On Wed, Nov 29, 2017 at 04:33:39PM +0100, Pascal Withopf wrote:
> Which means I have the following certificate chain:
> root.pem -> serverCA.pem -> server.pem
>
> But when I try to make a connection I see following error at the client
> side:
> Error with certificate at
ey.pem serverCAcert.pem rootcert.pem >
server.pem
Which means I have the following certificate chain:
root.pem -> serverCA.pem -> server.pem
But when I try to make a connection I see following error at the client
side:
Error with certificate at depth: 1
issuer = /C=XX/ST=XX/L=test/O=Testorganisat
ril 21, 2017 3:37 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Subject: Re: [openssl-users] Certificate chain validation
You are asking two different questions.
The certificates that the *client* sends are specified by the various “use
certficiate” API’s. No chain is buil
ssl-users@openssl.org>
Subject: Re: [openssl-users] Certificate chain validation
On 21/04/2017 03:37, Lei Kong wrote:
>
> When validating a certificate issued by an intermediate certificate
> authority, I noticed that I need to install both the root and the
> intermediate CA certificate
You are asking two different questions.
The certificates that the *client* sends are specified by the various “use
certficiate” API’s. No chain is built. See
doc/man3/SSL_CTX_use_certificate.pod, especially the “use certificate chain
file” API.
As for what the *server* does, it tries to use
SSL_CTX_load_verify_locations<https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_load_verify_locations.html>.”
From: Lei Kong<mailto:leik...@msn.com>
Sent: Friday, April 21, 2017 2:10 PM
To: openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Subject: RE: [openssl-users]
To: openssl-users@openssl.org
Subject: [openssl-users] Certificate chain validation
When validating a certificate issued by an intermediate certificate authority,
I noticed that I need to install both the root and the intermediate CA
certificate locally (with update-ca-certificates on ubuntu 16.04
On 21/04/2017 03:37, Lei Kong wrote:
When validating a certificate issued by an intermediate certificate
authority, I noticed that I need to install both the root and the
intermediate CA certificate locally (with update-ca-certificates on
ubuntu 16.04). Verification fails if only root CA cert
When validating a certificate issued by an intermediate certificate authority,
I noticed that I need to install both the root and the intermediate CA
certificate locally (with update-ca-certificates on ubuntu 16.04). Verification
fails if only root CA cert is installed (intermediate is not insta
Hi, I am new to the list and have a question where it seems I cannot find
the answer in archives here or in other sources.
We want to verify the certificate chain of an "official" certificate, but
including the revocation status of the intermediate certs, via CRL or
OCSP.
On Tue, February 21, 2017 12:16, Jakob Curdes wrote:
> Hi, I am new to the list and have a question where it seems I cannot find
> the answer in archives here or in other sources.
>
> We want to verify the certificate chain of an "official" certificate, but
> including the
Hi, I am new to the list and have a question where it seems I cannot find the
answer in archives here or in other sources.
We want to verify the certificate chain of an "official" certificate, but
including the revocation status of the intermediate certs, via CRL or OCSP.
f the code.
Thanks
chris
- Original Message -
From: Dr. Stephen Henson
To: Lei Sun ; openssl-users@openssl.org
Sent: Saturday, March 5, 2016 6:55 PM
Subject: Re: [openssl-users] verify certificate chain (in memory)
On Sat, Mar 05, 2016, Lei Sun wrote:
> Hi:
> In my project
On Sat, Mar 05, 2016, Lei Sun wrote:
> Hi:
> In my project I need to verify certificate chain sent from server. The
> chain has root->inter mediate -> server, 3 level chain. The server
> certificate files can be verified by "openssl verify" command:
>
&g
is a file (thus use LOOK_UP
API, etc).
Any references?
Thanks
chris
- Original Message -
From: Ángel González
To: openssl-users@openssl.org
Sent: Saturday, March 5, 2016 8:44 AM
Subject: Re: [openssl-users] verify certificate chain (in memory)
Lei Sun wrote:
> Hi:
> In my p
5, 2016 8:44 AM
Subject: Re: [openssl-users] verify certificate chain (in memory)
Lei Sun wrote:
> Hi:
> In my project I need to verify certificate chain sent from server.
> The chain has root->inter mediate -> server, 3 level chain. The
> server certificate files can be
Lei Sun wrote:
> Hi:
> In my project I need to verify certificate chain sent from server.
> The chain has root->inter mediate -> server, 3 level chain. The
> server certificate files can be verified by "openssl verify" command:
>
> openssl verify -CAfile root.c
uld cause
> it?
>
> Cheers,
> Frank
>
> Nicholas Mainardi
> Monday, February 01, 2016 8:57 PM
> I wrote this small program which takes as input X509 certificates,
> base64-encoded, parse them and build a certificate chain, which is
> eventually verified by x509_Verify_ce
em and build a certificate chain, which is
eventually verified by |x509_Verify_cert()|. The last certificate is
added to the trusted store if it's self-signed, in order to avoid
OpenSSL policy about self.signed certificates, as it's recommended in
this post
<https://zakird.com/201
I wrote this small program which takes as input X509 certificates,
base64-encoded, parse them and build a certificate chain, which is
eventually verified by x509_Verify_cert(). The last certificate is added to
the trusted store if it's self-signed, in order to avoid OpenSSL policy
On Sun, Oct 04, 2015 at 07:58:42AM -0400, Yan Seiner wrote:
> >I have a certificate from PositiveSSL for my email server. I have the
> >root certificate and the intermediate certs installed in /etc/ssl/certs/.
man c_rehash
> >However, I still cannot verify my certificate. I can't figur
CA
Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA
Limited, CN = COMODO RSA Domain Validation Secure Server CA
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN =
mail.seiner.com
ver
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN =
mail.seiner.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=mail.seiner.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
L
e url (ex. https://www.google.com), I found it will return 1.
why it can be pass verified even I do not set any root CA files on
windows. As I thought, we need root ca PEM files to verify certificate
chain.
Thanks~
--
Rejoice,I Desire!
___
openssl-
On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote:
> > I think there was also discussion on this list at some point suggesting
> > changing that "MAY" for omitting the root CA cert to a "SHOULD" or a
> > "MUST". (I think the argument for the latter was to reduce wasted bandwidth)
Sorry, th
);
X509_VERIFY_PARAM_free(param);
On Mon, Nov 17, 2014 at 3:43 PM, Viktor Dukhovni
wrote:
> On Mon, Nov 17, 2014 at 03:13:22PM +0800, Jerry OELoo wrote:
>
>> When I construct google's (www.google.com) certificate chain, it is
>> different with browser's
>>
>> [openssl A
On 09/01/2015 03:45, Jerry OELoo wrote:
Hi All:
I am using X509_STORE_CTX_get1_chain() to get web site's full certificate chain.
Now I am encounter an issue that some web site does not return
intermediate CA certificate but only web site leaf certificate.
For example.
Hi All:
I am using X509_STORE_CTX_get1_chain() to get web site's full certificate chain.
Now I am encounter an issue that some web site does not return
intermediate CA certificate but only web site leaf certificate.
For example. https://globaltrade.usbank.com
Below is certificate I get.
Su
On 29/12/14 10:00, Jerry OELoo wrote:
> Thanks Jeffrey & Matt
>
> Now I have a more question, I do not want to make code use tlsv1
> method and SSL_set_tlsext_host_name to query all website, I just want
> to when encounter this issue, then I will construct tlsv1 and set sni
> name to query certi
tion,
or what is correct coding process when support sni and non-sni
webiste. Thanks!
On Mon, Dec 29, 2014 at 5:20 PM, Matt Caswell wrote:
>
>
> On 29/12/14 08:32, Jerry OELoo wrote:
>> Hi.
>> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
>> base
On 29/12/14 08:32, Jerry OELoo wrote:
> Hi.
> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
> base on local root ca store. Now it works fine.
>
> But when I access this website, https://www.sgetvous.societegenerale.fr/
> I get a very strange resu
On Mon, Dec 29, 2014 at 3:43 AM, Jeffrey Walton wrote:
> On Mon, Dec 29, 2014 at 3:32 AM, Jerry OELoo wrote:
>> Hi.
>> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
>> base on local root ca store. Now it works fine.
>>
>> But
On Mon, Dec 29, 2014 at 3:32 AM, Jerry OELoo wrote:
> Hi.
> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
> base on local root ca store. Now it works fine.
>
> But when I access this website, https://www.sgetvous.societegenerale.fr/
> I get a very strang
Hi.
I am using X509_STORE_CTX_get1_chain() to construct certificate chain
base on local root ca store. Now it works fine.
But when I access this website, https://www.sgetvous.societegenerale.fr/
I get a very strange result.
Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1
On 18 December 2014 at 02:08, Jerry OELoo wrote:
>
> Hi Rich:
> But why browser Chrome can show all certificate path? How did it do?
> Thanks!
>
>
Browsers fix up mistakes like this in various ways - Firefox caches
intermediates and attempts to fix things by using them if the chain is
missing. IE
Hi Rich:
But why browser Chrome can show all certificate path? How did it do? Thanks!
On Wed, Dec 17, 2014 at 5:49 PM, Richard Moore wrote:
>
>
> On 17 December 2014 at 08:08, Jerry OELoo wrote:
>>
>> Hi All:
>> I am using openssl api to get website's certi
On 17 December 2014 at 08:08, Jerry OELoo wrote:
>
> Hi All:
> I am using openssl api to get website's certificate chain. Now, For
> normal website, it works fine.
> Now I encounter a website which certificate is expire,
> https://soknad.sparebank1.no
>
>
The server
Hi All:
I am using openssl api to get website's certificate chain. Now, For
normal website, it works fine.
Now I encounter a website which certificate is expire,
https://soknad.sparebank1.no
I use X509_STORE_CTX_get1_chain() to get certificate chain, and from
online help
(https://www.openss
On Mon, Nov 17, 2014 at 03:13:22PM +0800, Jerry OELoo wrote:
> When I construct google's (www.google.com) certificate chain, it is
> different with browser's
>
> [openssl API]
> www.google.com -> Google Internet Authority G2 -> GeoTrust Global CA
> -> Equif
Hi All:
I have used openssl 1.0.1j to construct certificate chain from https
web site. Now I can construct certificate chain correctly for
facebook, twitter.
When I construct google's (www.google.com) certificate chain, it is
different with browser's
[openssl API]
www.google.com
...@openssl.org] On Behalf Of Dave Thompson
Sent: Thursday, October 2, 2014 8:19 PM
To: openssl-users@openssl.org
Subject: RE: Certificate chain
> From: owner-openssl-us...@openssl.org On Behalf Of salih ahi
> Sent: Thursday, October 02, 2014 04:03
> I wrote an openssl server, which uses an o
ase_cert to trusted certificate list of client
> and any certificate signed with base_cert to show up without any
> certificate warnings. And I need the certificate chain tree to be
> parsed correctly by the browser for this.
You aren't clear, but I guess you *are* getting a brows
commonname = salih
base_cert.issuer.commonname = salih
What I want to do is, add base_cert to trusted certificate list of client
and any certificate signed with base_cert to show up without any certificate
warnings. And I need the certificate chain tree to be parsed correctly by
the browse
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 clien
> From: owner-openssl-us...@openssl.org On Behalf Of Sven Reissmann
> Sent: Thursday, May 29, 2014 12:24
> 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
On Thu, May 29, 2014 at 12:53:06PM -0700, David Li wrote:
> Say, I have a servercert.pem, serverkey.pem and cacert.pem. When
> using SSL_CTX_use_certificate_chain_file() to load a cert file as the
> second argument, I will have to construct the file like this:
>
> cat servercert.pem serverkey.pe
Hi,
Say, I have a servercert.pem, serverkey.pem and cacert.pem. When
using SSL_CTX_use_certificate_chain_file() to load a cert file as the
second argument, I will have to construct the file like this:
cat servercert.pem serverkey.pem cacert.pem > server.pem
and use server.pem in the API.
My qu
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 c
On 28/05/14 15:13, Salz, Rich wrote:
The signature on a certificate is made using the key of its parent CA. So that
means that the parent CA uses an RSA key and not an ECDSA key.
I thought the spec says the cert should be signed with the same key type. Not
sure which spec, sadly. :( And tha
> So the "same key type" rule only applies to TLS <=1.1. I'm not aware of any
> implementation that actually enforce this rule though.
Thanks for posting the references!
/r$
--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rs...@jabber.me; Twitter: RichSalz
___
> The signature on a certificate is made using the key of its parent CA. So
> that means that the parent CA uses an RSA key and not an ECDSA key.
I thought the spec says the cert should be signed with the same key type. Not
sure which spec, sadly. :( And that consensus was that this is a mista
On Wed, May 28, 2014, Sverre Moe wrote:
> I found something quite peculiar with my ECC Certificate from DigiCert.
>
> Signature algorithm used in this Certificate:
> Shown in Chromium:
> PKCS #1 SHA-256 with RSA-encryption
> Output in a Java program with debugging -Djava.net.debug=ssl:
>
I found something quite peculiar with my ECC Certificate from DigiCert.
Signature algorithm used in this Certificate:
Shown in Chromium:
PKCS #1 SHA-256 with RSA-encryption
Output in a Java program with debugging -Djava.net.debug=ssl:
Algorithm: [SHA256withRSA]
Shouldn't it actually be S
> 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 -> ol
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
trus
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:
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 sh
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:
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 truste
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 -unt
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 subCA.pem subCA2.pem
But, should't it also be possible to only veri
On Thu, Mar 13, 2014 at 12:07:09PM +0530, Harshal Talele wrote:
> I have now added server cert, private key and intermediate certificates
> in one file and reading them using SSL_CTX_use_certificate_chain_file()
> API.
>
> But one thing I want to understand. My server certificate is self-signed.
Thanks Victor.
I believe this was the problem.
I have now added server cert, private key and intermediate certificates in
one file and reading them using SSL_CTX_use_certificate_chain_file() API.
But one thing I want to understand. My server certificate is self-signed.
And intermediate certificat
On Mon, Mar 10, 2014 at 01:38:46PM +0530, Harshal Talele wrote:
> As a matter of fact with use of with use of
> SSL_CTX_use_certificate_chain_file() API SSL handshake continues to fail
You must put all the PEM certificates (leaf certificate and intermediate CAs)
in the *same* file. With the leaf
As a matter of fact with use of with use of
SSL_CTX_use_certificate_chain_file() API SSL handshake continues to fail
with error "
As you have mentioned Victor, I am using SSL_CTX_use_certificate_file() API
to read cert.pem which contains server certificate & private key.
Now I have another file cha
On Sat, Mar 08, 2014 at 08:26:54PM +0530, Harshal Talele wrote:
> In my case cert.pem file contains private key too.
> I wan to understand if I have to be use intermediate certificates in SSL
> handshake is there any specific way in which we have to populate SSL_CTX
> structure?
>
> I have tried
Thank you for your reply Meer.
In my case cert.pem file contains private key too.
I wan to understand if I have to be use intermediate certificates in SSL
handshake is there any specific way in which we have to populate SSL_CTX
structure?
I have tried using SSL_CTX_use_certificate_chain_file() AP
Harshal,
Check parameter 2 on SSL_CTX_use_PrivateKey_file(). It should be a pointer to
the name of the file that contains the private key, not the certificate file.
As an example on my (working) prototype server I use the following:
// Define whatever ciphers you want. I used AES-128. Client
Hello,
I am creating a SSL server /client architecture.
Wherein I am using code similar to mentioned below for populating my
Server's SSL_CTX
ret = SSL_CTX_use_certificate_file(sslctx, "/tmp/certs.pem",
SSL_FILETYPE_PEM);
if(ret != 1)
{
return false;
}
stackoverflow.com/questions/6646841/what-is-the-difference-between-x509-store-and-x509-store-ctx
http://www.openssl.org/docs/ssl/SSL_CTX_set_cert_store.html
This may also be useful:
http://stackoverflow.com/questions/16291809/openssl-programatically-verify-certificate-chain-in-c-in-memory-certs
--
I'm trying to add some key and certificate validation code to help
diagnose potential issues.
X509_verify allows me to verify an X509 and EVP_PKEY pair.
verify.c has certificate validation code, but it appears to work from
the file system (X509_STORE_add_lookup(), X509_LOOKUP_file(),
X509_LOOKUP_
Graham Leggett wrote:
> In a typical client certificate scenario, you might verify that a certificate
> chain is complete, not expired, and trusted by a root certificate. If you
> were to choose a way to authorize the certificate over and above the check
> that the cert is vali
Hi all,
In a typical client certificate scenario, you might verify that a certificate
chain is complete, not expired, and trusted by a root certificate. If you were
to choose a way to authorize the certificate over and above the check that the
cert is valid, you might store it's subject
> From: owner-openssl-us...@openssl.org On Behalf Of sherry
> Sent: Friday, 16 August, 2013 20:09
> Hi Dirk,
>
(This is an open list, so I'll answer.)
Aside: I hope you know RSA 1024 is now considered
under some threat (though not actually broken),
and not safe for a projected 10-year lifeti
N = server
error 20 at 0 depth lookup:unable to get local issuer certificate
Thanks so much!
Sherry
--
View this message in context:
http://openssl.6102.n7.nabble.com/create-certificate-chain-tp44046p46205.html
Sent from the OpenSSL - User mailing list archive at
Try these:
- split the certificates from your CA/cecert.pem into individual files
with correct hashes
- run "strace -eopen openssl verify -CApath
client.cert"
--
Erwann ABALEA
Le 04/06/2013 09:02, Leon Brits a écrit :
Hi all,
I have just created a new CA which has the extension to allow
Hi all,
I have just created a new CA which has the extension to allow client
authentication. My previous CA worked fine without this extension but some
client application now requires that I set it. So I've created a new client key
pair and signed it with the new CA, but when I use openssl veri
>From: owner-openssl-us...@openssl.org On Behalf Of Leon Brits
>Sent: Sunday, 02 June, 2013 10:11
>I have just created a new CA which has the extension to allow
>client authentication. My previous CA worked fine without this
>extension but some client application now requires that I set it.
Th
Hi all,
I have just created a new CA which has the extension to allow client
authentication. My previous CA worked fine without this extension but
some client application now requires that I set it. So I've created a
new client key pair and signed it with the new CA, but when I use
openssl verif
1 - 100 of 276 matches
Mail list logo
