Hello,
I'd like a clarify a little bit about multithreaded use of X509_verify_cert.
Use case: I want connections to be accepted and served in a network
thread and delegate all certificate checking to another thread (or even
thread pool). CA for all certificates to be checked is stored in a
si
Indeed. Downloading the intermediate CA bundle from Thawte and installing it as
a chain certificate file into Apache did the trick!
Thank you very much,
Ron Arts
Op 12 jan. 2011 om 05:17 heeft "Dave Thompson" het
volgende geschreven:
>> From: owner-openssl-us...@openssl.org On Behalf Of Ron
> From: owner-openssl-us...@openssl.org On Behalf Of Ron Arts
> Sent: Tuesday, 11 January, 2011 17:52
> I just renewed my Thawte webserver certificate. This
> certicifate seems to work fine
> with various browsers I tried, but it curl, wget on CentOS
> 5.5 are not able to verify it:
> I followe
On Tue, Jan 11, 2011 at 11:51:47PM +0100, Ron Arts wrote:
> I just renewed my Thawte webserver certificate. This certicifate seems to
> work fine with various browsers I tried, but it curl, wget on CentOS 5.5
> are not able to verify it:
Browsers often have a fairly large set of trusted roots an
Hello,
I just renewed my Thawte webserver certificate. This certicifate seems to work
fine
with various browsers I tried, but it curl, wget on CentOS 5.5 are not able to
verify it:
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET
Hello,
> I am trying to verify a certificate with the folowing command line on a
> windows 32 bit plateform:
>
> C:\OpenSSL\bin> openssl verify -CAfile d:\cert.pem d:\cert2.pem
>
> It replies me:
>
> d:\cert2.pem: /C=FR/ST=Cote d Or/L=Saint Apollinaire/O=societe des AUTOROUTES
> PARIS RHIN RHO
Hi
I am trying to verify a certificate with the folowing command line on a windows
32 bit plateform:
C:\OpenSSL\bin> openssl verify -CAfile d:\cert.pem d:\cert2.pem
It replies me:
d:\cert2.pem: /C=FR/ST=Cote d Or/L=Saint Apollinaire/O=societe des AUTOROUTES
PARIS RHIN RHONE/OU=DTR/DRTM/RT/OU=P
On 3/17/06, Erwann ABALEA <[EMAIL PROTECTED]> wrote:
> Hodie post. Id. Mar. MMVI est, Kyle Hamilton scripsit:
>
> There's no problem with the X.509 model.
>
> You're right that a certificate signed by a CA can be revoked by
> another CA which has the same exact DN (not CN). The reason is simple:
>
Hodie post. Id. Mar. MMVI est, Kyle Hamilton scripsit:
> ...except that it's not.
>
> A later certificate (w/ different public key) with the same CN can
> issue revocations against an earlier certificate with the same CN, per
> X.509. That's part of the problem with the entire X.509 model in the
I think David may have a point here. On the client side you have a list of CA's you trust so therefore other CA's will not be accepted. It is a big problem that you can revoke other Certs with the same CN though.David Schwartz <[EMAIL PROTECTED]> wrote: > ...except that it's not.>> A later certifi
I think David may have a point here. On the client side you have a list of CA's you trust so therefore other CA's will not be accepted. It is a big problem that you can revoke other Certs with the same CN though.David Schwartz <[EMAIL PROTECTED]> wrote: > ...except that it's not.>> A later certifi
> ...except that it's not.
>
> A later certificate (w/ different public key) with the same CN can
> issue revocations against an earlier certificate with the same CN, per
> X.509. That's part of the problem with the entire X.509 model in the
> first place.
Is this so without the newer c
...except that it's not.
A later certificate (w/ different public key) with the same CN can
issue revocations against an earlier certificate with the same CN, per
X.509. That's part of the problem with the entire X.509 model in the
first place.
On 3/15/06, David Schwartz <[EMAIL PROTECTED]> wrot
> So if what you are saying is true then i could call
> myself the same name as a trusted CA authority when
> making my root CA and the browser will think i am a
> trusted CA. Is that correct?. It seems too simple to be true.
No. CAs are not identified by name but by key. That's the
michael Dorrian wrote:
So if what you are saying is true then i could call myself the same name
as a trusted CA authority when making my root CA and the browser will
think i am a trusted CA. Is that correct?. It seems too simple to be
true.
1. If you forge a root CA certificate...
2. ...
So if what you are saying is true then i could call myself the same name as a trusted CA authority when making my root CA and the browser will think i am a trusted CA. Is that correct?. It seems too simple to be true."Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote: On Wed, Mar 15, 2006, michae
On Wed, Mar 15, 2006, michael Dorrian wrote:
> First of all thank you for your reply. I read one of your previous replies
> to the following post and this seems to be what i need.
> http://www.mail-archive.com/openssl-users@openssl.org/msg20673.html X509_AUX
> is a "trusted certificate" format "W
First of all thank you for your reply. I read one of your previous replies to the following post and this seems to be what i need. http://www.mail-archive.com/openssl-users@openssl.org/msg20673.html X509_AUX is a "trusted certificate" format "With PEM_read_bio_X509_AUX if the certificate is tru
On Tue, Mar 14, 2006, michael Dorrian wrote:
> Thanks for your reply. It makes sense that it does not trust any authority
> by default. I will try to research these functions a little more but it may
> be difficult to find a way to actually check that it was signed by a
> trusted authority. Anywa
Thanks for your reply. It makes sense that it does not trust any authority by default. I will try to research these functions a little more but it may be difficult to find a way to actually check that it was signed by a trusted authority. Anyway i appreciate the help.Kyle Hamilton <[EMAIL PROTECTE
OpenSSL does not, by default, trust ANY certification authorities.
This means that you have to give it the certs directly.
It looks like the only way to do that at this point is to call the
(mostly) undocumented SSL_CTX_set_cert_store() function. The best
documentation at this point is the sourc
I know SSL_CTX_load_verify_locations() loads the CAs you trust from a pem file that you store locally on your client machine but i cannot use this function as i dont want to read a pem file on the client side. I want to know if you can check to see if the server certificate presented was signed by
Is there any way for me to verify that the contents of the
certificates that I am loading are okay? In addition, can I check to
see if the chained certificate holds an RSA certificate?
--
Nadav Golombick
__
OpenSSL Project
nk S.A.)
Subject: Re: verifying certificate
Gisela Acosta wrote:
>
> Hi,
> Thanks for your answer.
&
Gisela Acosta wrote:
>
> Hi,
> Thanks for your answer.
> Your are right. The certificate that I've used isn't certified for email. It's
> Verisign Netscape Object Signing* Digital ID.
> I need to verify a signed file, not an email.
> Should I use X509_PURPOSE_SMIME_SIGN or another one?
> What i
Subject: Re: verifying certificate
Gisela Acosta wrote:
>
> Hi,
> I've signed my message with a netscape certificate. When I try to verify it,
the
> following err
Gisela Acosta wrote:
>
> Hi,
> I've signed my message with a netscape certificate. When I try to verify it, the
> following error occurs:
> 26: unsupported certificate purpose
> I set the ctx structure with X509_PURPOSE_SMIME_SIGN, like it's in verify.c.
> I tried setting the structure whith X509
Hi,
I've signed my message with a netscape certificate. When I try to verify it, the
following error occurs:
26: unsupported certificate purpose
I set the ctx structure with X509_PURPOSE_SMIME_SIGN, like it's in verify.c.
I tried setting the structure whith X509_PURPOSE_ANY, and it seems to work
Hi,
I've signed my message with a netscape certificate. When I try to verify it, the
following error occurs:
26: unsupported certificate purpose
I set the ctx structure with X509_PURPOSE_SMIME_SIGN, like it's in verify.c.
I tried setting the structure whith X509_PURPOSE_ANY, and it seems to work
29 matches
Mail list logo