On 9/4/22 01:55, Roger James via openssl-users wrote:
As I mentioned in an earlier post you need version 1.1 or later of
openssl to successfully validate post September 30, 2021 Lets Encrypt
certificates. The version on your Centos system is 1.0.
The CentOS system was just another VM I ran the
On Sun, Sep 04, 2022 at 08:55:26AM +0100, Roger James via openssl-users wrote:
> As I mentioned in an earlier post you need version 1.1 or later of openssl
> to successfully validate post September 30, 2021 Lets Encrypt certificates.
> The version on your Centos system is 1.0.
This is not quite
As I mentioned in an earlier post you need version 1.1 or later of openssl
to successfully validate post September 30, 2021 Lets Encrypt certificates.
The version on your Centos system is 1.0.
nclude the ISRG X1 root, and it does not when you override
the CAfile, and CApath fails to bridge the gap.
> If I use a file that DOES contain the root cert (one of the files
> downloaded by certbot) then I can get it to pass with -untrusted, but
> not -CAfile:
>
> [root@certs
lly be using the "-untrusted" option not the "-CAfile" option:
# cert=/etc/ssl/certs/local/DOMAIN.wildcards.pem
# openssl verify -untrusted "$cert" "$cert"
This adds the untrusted intermediate certs from the cert file to
the dataset, without shadowing th
On Fri, Sep 02, 2022 at 09:42:13PM -0600, Shawn Heisey via openssl-users wrote:
> On an AlmaLinux 8.6 VM hosted in Proxmox:
>
> [root@certs ~]# openssl verify -CAfile
> /etc/ssl/certs/local/DOMAIN.wildcards.pem
> /etc/ssl/certs/local/DOMAIN.wildcards.pem
> C = US, O = Let&
On 3 September 2022 19:26:50 Shawn Heisey via openssl-users
wrote:
On 9/2/22 21:42, Shawn Heisey via openssl-users wrote:
Other bare metal systems and their results with the same PEM file:
Verifies on Proxmox (the one running the VM) with openssl 1.1.1n
Verifies on Ubuntu 22.04 with ope
On 3 September 2022 19:26:50 Shawn Heisey via openssl-users
wrote:
On 9/2/22 21:42, Shawn Heisey via openssl-users wrote:
Other bare metal systems and their results with the same PEM file:
Verifies on Proxmox (the one running the VM) with openssl 1.1.1n
Verifies on Ubuntu 22.04 with opens
On 9/2/22 21:42, Shawn Heisey via openssl-users wrote:
Other bare metal systems and their results with the same PEM file:
Verifies on Proxmox (the one running the VM) with openssl 1.1.1n
Verifies on Ubuntu 22.04 with openssl 3.0.2
Fails on CentOS 7.5.1804 with openssl 1.0.2k-fips
Additional te
On an AlmaLinux 8.6 VM hosted in Proxmox:
[root@certs ~]# openssl verify -CAfile
/etc/ssl/certs/local/DOMAIN.wildcards.pem
/etc/ssl/certs/local/DOMAIN.wildcards.pem
C = US, O = Let's Encrypt, CN = R3
error 2 at 1 depth lookup: unable to get issuer certificate
error /etc/ssl/certs/
On Mon, 16 Aug 2021 16:30:05 +0200,
Ken Goldman wrote:
>
> On 8/16/2021 10:04 AM, Viktor Dukhovni wrote:
> >> It seems as though the 'verify' command checks the issuer,
> >> but not the signature of the certificate - the last parameter.
> >
> > As documented.
>
> Then I am not understanding the d
As documented, the self-signature checks on self-signed certs are by
default skipped. If your trust store can be modified by untrusted
actors, self-signature checks won't help you.
If you want to check the self-signature, pass the "-check_ss_sig"
option.
--
Viktor.
On 8/16/2021 10:04 AM, Viktor Dukhovni wrote:
It seems as though the 'verify' command checks the issuer,
but not the signature of the certificate - the last parameter.
>
As documented.
Then I am not understanding the documentation.
https://www.openssl.org/docs/man1.1.1/man1/verify.html
says
> On 16 Aug 2021, at 9:41 am, Ken Goldman wrote:
>
> Adding -check_ss_sig correctly causes a signature failure.
Well, there you are. See the documentation of "check_ss_sig":
-check_ss_sig
Verify the signature on the self-signed root CA. This is
disabled by default because it d
It doesn't seem to be verifying the signature on the certificate
parameter. Version 1.1.1k.
I create an incorrectly signed self signed certificate and convert it from
der to pem.
A basic
openssl verify -CAfile c1.pem c1.pem
Returns OK, even though the signature is bad. Why?
Ed
On 2021-06-17 15:49, Viktor Dukhovni wrote:
On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote:
When I compare those, they are exactly the same. But that's the thing, I
think server.sig.decrypted should be prepended with a sha256 designator
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 0
On Sat, Jun 12, 2021 at 10:20:22PM +0200, Gaardiolor wrote:
> When I compare those, they are exactly the same. But that's the thing, I
> think server.sig.decrypted should be prepended with a sha256 designator
> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20, which is
> missing. I do s
Hi,
On 12/06/21 22:20, Gaardiolor wrote:
Hello,
My openssl-1.0.2k-21.0.1.el7_9.x86_64 verify fails with HSM-signed
certificates. The HSM is causing other issues and is likely
misbehaving, I think this is a HSM bug. I'm sure I'm using the correct
server.crt and rootca.crt.
$ open
Hello,
My openssl-1.0.2k-21.0.1.el7_9.x86_64 verify fails with HSM-signed
certificates. The HSM is causing other issues and is likely misbehaving,
I think this is a HSM bug. I'm sure I'm using the correct server.crt and
rootca.crt.
$ openssl verify -CAfile rootca.crt server.crt
Hi all,
While trying to verify a client certificate using openssl verify with
-crl_check_all and –partial_chain options set , I get the following error:
error 8 at 1 depth lookup: CRL signature failure
error client1.pem: verification failed
Here is the command used:
openssl verify -crl_check
Thanks, I provided some input regarding off by one calculation of plen
still present in the patch.
You are very much correct on the definition of self-issued; rfc5280,
"A certificate is self-issued if the same DN appears in the subject
and issuer fields (the two DNs are the same if they match acco
> On Oct 4, 2018, at 6:25 AM, Viktor Dukhovni
> wrote:
>
> but this corner-case is not correct, the concept of "self-issued"
> only applies to CAs, so for the leaf to be skipped it would have
> the be a self-issued CA. Try the patch below:
I've simplified the patch in https://github.com/ope
On Thu, Oct 04, 2018 at 02:07:55PM +0200, Peter Magnusson wrote:
> Modulus of evilca.pem begins with 00:cd:ba:9f and modulus of
> evilserver.pem begins with 00:af:83:6f, so they are different even if
> both have Subject: C=SE, ST=EvilServer, L=EvilServer, O=EvilServer,
> OU=EvilServer, CN=EvilSer
by evilca.pem.
>
> More specifically, we see that in this test the leaf server certificate
> has the same subject and issuer, so EXFLAG_SI is set for that
> certificate, and it did not count in the path length:
>
> $ /usr/local/bin/openssl verify -show_chain -verbose -trusted
r that
certificate, and it did not count in the path length:
$ /usr/local/bin/openssl verify -show_chain -verbose -trusted root.pem
-untrusted untrusted.pem evilserver.pem
evilserver.pem: OK
Chain:
depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
EvilServ
Is this expected? (plen > (x->ex_pathlen + proxy_path_length + 1))
evaluates to false (constraint not violated) when checking constraint
0 against plen=1 (constraint violated as far as I can understand?).
Doesn't make much sense to me. Is there something I haven't understood
about how the constra
asic"
X509v3 Basic Constraints: critical
CA:TRUE
openssl verify -verbose -CAfile root.pem -untrusted untrusted.pem evilserver.pem
evilserver.pem: OK
On Wed, Oct 3, 2018 at 4:51 PM Viktor Dukhovni
wrote:
>
> On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Mag
On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Magnusson wrote:
> $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem
> evil.pem
> evil.pem: OK
This is expected to work when intermediate.pem has pathlen 0, because
you're verifying "evil.pem" as a
Hi,
It is my understanding "openssl verify" should raise
X509_V_ERR_PATH_LENGTH_EXCEEDED should be raised if pathlen=0
intermediate issues a new CA, but that does not seem to occur when I
test with a couple pf openssl versions.
I am not sure due to limited understanding of the code
Thanks
-Messaggio originale-
Da: openssl-users [mailto:openssl-users-boun...@openssl.org] Per conto di
Viktor Dukhovni
Inviato: venerdì 2 marzo 2018 16:38
A: openssl-users@openssl.org
Oggetto: Re: [openssl-users] openssl verify command doesn't work
> On Mar 2, 2018, at
> On Mar 2, 2018, at 9:49 AM, CAMPETTO CLAUDIO wrote:
>
>>>>> openssl verify -CAfile CATest2.cacert.pem -crl_check -crlfile
>>>>> CATest2.crl.pem testrinnovo1_nuovo.pem
>
> usage: verify [-verbose] [-CApath path] [-CAfile file] [-truste
>>>>openssl version
openssl 1.0.2k-fips
>>>>man verify
VERIFY(1)
OpenSSL
VERIFY(1)
NAME
ve
A lot depends on what you mean by "verify", too. TLS endpoints should perform
a large number of checks on certificates; some of them aren't relevant for your
purposes, and others might not be.
For example, a TLS client such as a browser will check whether the received
entity certificate identi
Also consider using the functions that the "openssl verify"
command uses (source file: apps/verify.c), perhaps from a
bulk process that can be run on each CPU node on your
compute cluster. With a little thought, these can be done
efficiently, with lots of reused (i.e. not repeated) act
Depends what information you need - if you just need a binary valid/not
valid then prune it first then verify. If you want a more fine grained data
set then don't. Write some code - forking and running openssl verify each
time will be insanely slow - don't do that. I doubt you rea
Hello,
I am a CS graduate student and doing a measurement study regarding the SSL
ecosystem. I have approximately 1 billion SSL certificates and I would like to
run openssl verify on each certificate to sift out invalid certificates. My
major concern, as you might guess, is whether doing this
On 18/05/2016 21:38, Walter H. wrote:
On 18.05.2016 21:10, Viktor Dukhovni wrote:
On May 18, 2016, at 1:26 PM, Walter H.
wrote:
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt
-trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem
/tmp/chain.pem contains a root certificate
On 18.05.2016 21:10, Viktor Dukhovni wrote:
On May 18, 2016, at 1:26 PM, Walter H. wrote:
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first
-untrusted /tmp/chain.pem /tmp/cert.pem
/tmp/chain.pem contains a root certificate
/tmp/cert.pem contains a certificate that
> On May 18, 2016, at 1:26 PM, Walter H. wrote:
>
> openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first
> -untrusted /tmp/chain.pem /tmp/cert.pem
>
> /tmp/chain.pem contains a root certificate
> /tmp/cert.pem contains a certificate that wa
Hello,
when
running this:
openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt
-trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem
/tmp/chain.pem contains a root certificate
/tmp/cert.pem contains a certificate that was signed by this root
certificate;
I get the following
On Tue, May 03, 2016, Graham Leggett wrote:
> Hi all,
>
> I am trying to use ???openssl verify??? as a sanity check to determine
> whether a set of certificates are sane and valid in a script that issues (or
> reissues) the certificates, and I???m struggling with th
Hi all,
I am trying to use “openssl verify” as a sanity check to determine whether a
set of certificates are sane and valid in a script that issues (or reissues)
the certificates, and I’m struggling with the output of the “openssl verify”
command.
This is output I get while verifying three
Thank you both for your responses.
I changed to cross-certifying at the root and it worked as expected.
However, cross-certification doesn't have to be at the root, going by
RFC 4949's definition. Neither do any of my text books on the subject
state that it has to be at the root CA level.
N
> On Dec 31, 2015, at 12:55 PM, Jakob Bohm wrote:
>
>> You're not supposed to create two different untrusted intermediate
>> certificates, include both and hope for a good outcome. OpenSSL
>> does not try all possible untrusted intermediates at every depth
>> in the chain, that has exponential
On 31/12/2015 18:12, Viktor Dukhovni wrote:
On Thu, Dec 31, 2015 at 04:56:08PM +, Gareth Williams wrote:
I now try to cross-certify by adding another Root CA (Example Root CA) and
use that to sign the original Gareth Williams Policy CA certificate signing
request, then add this new certific
On Thu, Dec 31, 2015 at 04:56:08PM +, Gareth Williams wrote:
> I now try to cross-certify by adding another Root CA (Example Root CA) and
> use that to sign the original Gareth Williams Policy CA certificate signing
> request, then add this new certificate to the chain.crt file:
>
> Gareth Wi
ity (a web
server) all with a really original naming convention as follows:
Gareth Williams Root CA
Gareth Williams Policy CA
Gareth Williams Issuing CA
office.garethwilliams.me.uk (test webserver)
I've concatenated the policy CA and issuing CA certificate into a single
file, and running:
Hello,
openssl verify -CAfile root.pem -untrusted issuer.pem srvr.pem
gives this output
srvr.pem: OK
but
openssl verify -CAfile root.pem -crl_check -untrusted issuer.pem srvr.pem
gives this:
srvr.pem: C = US, OU = Domain Control Validated, CN = revoked.grc.com
error 3 at 0 depth lookup:unable
Hi,
Can following behaviour be confirmed as expected?
OpenSSL verify test (test_verify) fails
Env-
c_rehash run using Cygwin. Run c_rehash on /path/to/certs/demo
Cmd -
openssl verify -CApath ../certs/demo ../certs/demo/*.pem
Cause -
Symbolic links (from hash.0 to file.pem) created by c_rehash
-- Forwarded message --
From: "Deepak"
Date: Jan 31, 2015 8:05 AM
Subject: OpenSSL 'verify' command and c_ rehash script on Cygwin
To:
Cc:
Hi,
Can following behaviour be confirmed as expected?
OpenSSL verify test (test_verify) fails
Env-
c_rehash r
Hi,
Can following behaviour be confirmed as expected?
OpenSSL verify test (test_verify) fails
Env-
c_rehash run using Cygwin. Run c_rehash on /path/to/certs/demo
Cmd -
openssl verify -CApath ../certs/demo ../certs/demo/*.pem
Cause -
Symbolic links (from hash.0 to file.pem) created by
projected 10-year lifetime.
> root@dev12042:~/cert# openssl verify -CAfile ca.crt
> ca-int.crt server.crt
> ca-int.crt: OK
> server.crt: CN = server
> error 20 at 0 depth lookup:unable to get local issuer certificate
'verify' validates each cert, individually, against only
t
Hi Dirk,
Thanks for your post. You seems to be so knowledgeable! I tried your
commands, but I am not able to verify with "openssl verify". Could you
please help? Following is the command sequence:
root@dev12042:~/cert# openssl genrsa -out ca.key 1024
Generating RSA private key, 102
Hello,
I've encountered a strange problem with multiple CRLs and authentication.
I've been using a script to download and prepare roughly 200 CRLs, placing
them in the correct folder and rehashing them as is proper. I tell (in this
case) freeradius to use the external command open
"openssl/apps/verify.c")
The following command line will verify that a certificate is valid, and has
not been revoked:
openssl verify -CAfile ca.crt -CRLfile revoked.crl -crl_check
certToBeCheckked.crt
Interestinglt, the -CRLfile command line option seems to be completely
undocumen
ams return non-zero for a failure. E.g., diff returns non-zero
> if there's a difference. grep return non-zero if it doesn't find anything.
>
> Non-zero doesn't mean 'the app didn't work correctly.' It means something
> useful specific to the application. In
ere's a difference. grep return non-zero if it doesn't
find anything.
Non-zero doesn't mean 'the app didn't work correctly.' It means
something useful specific to the application. In the case of 'openssl
verify', what makes sense to me would be:
0
OpenSSL app worked as expected, and that is what 0 means (EXIT_SUCCES) in C
programming. The fact that verification wasn't successful does not mean
OpenSSL app didn't work correctly. I think you either have to write your
own app (or maybe just modifiy OpenSSL verify app to return wha
In testing my regression tests, I supply a bad CA certificate to force
the verify to fail.
I use:
> openssl verify -CAfile cacert.pem cert.pem
It printed this, which I expected.
"error 20 at 0 depth lookup: ..."
However, when my bash script checks the return code, it is sti
>From: owner-openssl-us...@openssl.org On Behalf Of Peter Eckersley
>Sent: Monday, 09 July, 2012 19:59
># now try to verify it. Note that "allcerts" was a poorly chosen
>directory name. It should have been allCAs...
>openssl verify -untrusted twitter.co
erts
> ./inspect twitter.com.results
> cd certs
>
> # now try to verify it. Note that "allcerts" was a poorly chosen
> directory name. It should have been allCAs...
>
> openssl verify -untrusted twitter.com.results_2.pem -CApath ../allcerts/
>
Note that "allcerts" was a poorly chosen directory
name. It should have been allCAs...
openssl verify -untrusted twitter.com.results_2.pem -CApath ../allcerts/
twitter.com.results_1.pem
# with openssl 0.9.8*, the above command will print
# twitter.com.results_1.pem: OK
#
# but with 1
Hello All,
I have a Linux system running openssl 0.9.8r.
I have scripts that automatically download the latest CRL (crl.pem)
every 24 hours.
I also have several certificates on the system that's actively being
used by various applications.
EXACTLY HOW can I use the &qu
Array
> -Load Public Key from PEM files into OpenSSL use BIO Object
> -Call OpenSSL Verify and returns Invalid Signature.
>
Testing:
-Java Signature Validate fine within Java
- OpenSSL generated signature validates fine within OpenSSL.
They do not validate with each other though.
> C
t problems
verify due to string encoding problems.
-Base64 Encode the Signature
-Transmit it over a Socket with Message Concatenated at end
-Receive it over a Socket in C with OpenSSL Lob
-Load Public Key from PEM files into OpenSSL use BIO Object
-Call OpenSSL Verify and returns Invalid Signatur
Hi,
To test some certificates that I have made with my own rootca, I have
been trying to use s_server and s_client commands with the openssl
command line app.
On a quick read of the docs, I thought the Verify (server) and verify
(client) opts would do the job. But alas no. After testing
On Wed, Mar 09, 2011, Ralph Holz wrote:
>
> Sorry again, but this is somewhat confusing. Your words seem to imply that
> the correctness of the chain leading up to the root CA is indeed evaluated
> (else why bother about the CA cert?). Yet the docs say about -purpose:
> "Without this option no ch
Hi,
> > No it just means that most certificates could (in theory) be use as SSL
> > > server
> > > certificates. If you had appropriate extensions restrictions (e.g.
> extended
> > > key usage or the deprecated netscape certificate type) you'd notice the
> > > difference.
> > >
> >
> > Thanks for
On Wed, Mar 09, 2011, Ralph Holz wrote:
> Hi Steve,
>
> On 9 March 2011 13:03, Dr. Stephen Henson wrote:
>
> > > Am I correct in surveying that openssl verify uses a default of
> > "sslserver"
> > > for -purpose?
> > >
> >
> >
Hi Steve,
On 9 March 2011 13:03, Dr. Stephen Henson wrote:
> > Am I correct in surveying that openssl verify uses a default of
> "sslserver"
> > for -purpose?
> >
>
> No it just means that most certificates could (in theory) be use as SSL
> serve
On Wed, Mar 09, 2011, Ralph Holz wrote:
> Good day,
>
> The following is a question re: openssl verify.
>
> In the openssl docs, I have found that "no chain verification is done if the
> option "-purpose is not set". I just checked with a few test cases (certs
Good day,
The following is a question re: openssl verify.
In the openssl docs, I have found that "no chain verification is done if the
option "-purpose is not set". I just checked with a few test cases (certs
from HTTPs server, chain length at least 3) and found that the output
can see :
error:0906D06C:PEM routines:PEM_read_bio:no start line
But this error happens everytime (even when it works), so, I dont think it's
related.
Any idea ?
Thanks
--
View this message in context:
http://old.nabble.com/OpenSSL-verify-fails-tp31008774p31008774.html
Sent from the Op
Michael Ströder writes:
> Bruce Stephens wrote:
[...]
>> Ah, my fault. Obvious in retrospect: Debian's openssl finds the root
>> cert because it's in the ca-certificates package!
>
> Did you use -CAfile as in my original posting when testing?
I did.
> Doesn't -CAfile set exclusively all trus
On Tue, Nov 09, 2010 at 01:45:15PM +, Bruce Stephens wrote:
> Michael Str??der writes:
>
> > Bruce Stephens wrote:
>
> [...]
>
> >> Ah, my fault. Obvious in retrospect: Debian's openssl finds the root
> >> cert because it's in the ca-certificates package!
> >
> > Did you use -CAfile as in
Bruce Stephens wrote:
> Bruce Stephens writes:
>
>> "Dr. Stephen Henson" writes:
>>
>> [...]
>>
>>> Is that unmodified OpenSSL 0.9.8o? If so that's peculiar I get the expected
>>> error here.
>>
>> No, it's Debian's 0.9.8o-2.
>
> Ah, my fault. Obvious in retrospect: Debian's openssl finds the
Bruce Stephens writes:
> "Dr. Stephen Henson" writes:
>
> [...]
>
>> Is that unmodified OpenSSL 0.9.8o? If so that's peculiar I get the expected
>> error here.
>
> No, it's Debian's 0.9.8o-2.
Ah, my fault. Obvious in retrospect: Debian's openssl finds the root
cert because it's in the ca-certi
"Dr. Stephen Henson" writes:
[...]
> Is that unmodified OpenSSL 0.9.8o? If so that's peculiar I get the expected
> error here.
No, it's Debian's 0.9.8o-2.
[...]
__
OpenSSL Project http://www.op
Bruce Stephens wrote:
> Erik Tkal writes:
>
>> Maybe that's a bug in OpenSSL 0.9.8o? The docs for verify say "It is
>> an error if the whole chain cannot be built up."
>
> Maybe, but I think it's just as reasonable to regard it as a bug in the
> docs.
>
> I think it's useful for verify to be a
Erik Tkal writes:
> Maybe that's a bug in OpenSSL 0.9.8o? The docs for verify say "It is
> an error if the whole chain cannot be built up."
Maybe, but I think it's just as reasonable to regard it as a bug in the
docs.
I think it's useful for verify to be able to verify chains from trust
anchor
Erik Tkal wrote:
> Your "rootcacert" is not a root cert, as it was issued by "C=US, ST=UT,
> L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com,
> CN=UTN-USERFirst-Client Authentication and Email". You need to append that
> cert as well to your CAfile.
Shouldn't it be possible
N=UTN-USERFirst-Client Authentication
> > and Email". You need to append that cert as well to your CAfile.
>
> That seems to be a change in behaviour. 0.9.8o is happy:
>
> brs% openssl version
> OpenSSL 0.9.8o 01 Jun 2010
>
> brs% openssl verify
wner-openssl-us...@openssl.org]
On Behalf Of Bruce Stephens
Sent: Wednesday, November 03, 2010 12:59 PM
To: openssl-users@openssl.org
Subject: Re: openssl verify fails
Erik Tkal writes:
> Hi Michael,
>
> Your "rootcacert" is not a root cert, as it was issued by "C=US,
>
hat cert as well to your CAfile.
That seems to be a change in behaviour. 0.9.8o is happy:
brs% openssl version
OpenSSL 0.9.8o 01 Jun 2010
brs% openssl verify -verbose -CAfile rootcacert.pem subcacert.pem
subcacert.pem: OK
brs% openssl verify -issuer_checks -CAfile rootcace
your CAfile.
Erik
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Michael Ströder
Sent: Wednesday, November 03, 2010 12:23 PM
To: openssl-users@openssl.org
Subject:
HI!
I'm feeling dumb since this simple command fails and I cannot see why:
$ openssl verify -CAfile rootcacert.pem subcacert.pem
subcacert.pem: C = DE, O = SCA Deutsche Post Com GmbH, CN = Signtrust CERT
Root CA 1:PN
error 2 at 1 depth lookup:unable to get issuer certificate
I've at
On Mon, Aug 30, 2010, Goran Rakic wrote:
> ?? ??, 30. 08 2010. ?? 20:38 +0200, Dr. Stephen Henson :
> >
> > I wouldn't advise changing the code in that way (FYI I wrote it). The normal
> > workaround in OpenSSL for broken encodings is to use the original encoding
> > by caching it. The
У пон, 30. 08 2010. у 20:38 +0200, Dr. Stephen Henson пише:
>
> I wouldn't advise changing the code in that way (FYI I wrote it). The normal
> workaround in OpenSSL for broken encodings is to use the original encoding
> by caching it. The attached three line patch adds this workaround for
> certifi
On Mon, Aug 30, 2010, Goran Rakic wrote:
> ?? ??, 29. 08 2010. ?? 04:17 +0200, Mounir IDRASSI :
> >
> > After some digging, I found that part of the problem is caused by the
> > functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file
> > crypto\asn1\a_int.c. At lines 244 and 314, th
Hodie III Kal. Sep. MMX, Goran Rakic scripsit:
[...]
> I read the other messages in this thread, but I am not an expert in the
> field so I do not know if openssl should add a support for "incorrect"
> serial numbers. In RFC 3280 there is a note about "Non-conforming CAs"
> where section "4.1.2.2 S
У нед, 29. 08 2010. у 04:17 +0200, Mounir IDRASSI пише:
>
> After some digging, I found that part of the problem is caused by the
> functions c2i_ASN1_INTEGER and d2i_ASN1_UINTEGER in file
> crypto\asn1\a_int.c. At lines 244 and 314, there is an if block that
> removes any leading zeros. Comment
Hodie IV Kal. Sep. MMX, Mounir IDRASSI scripsit:
[...]
> Specifically, Peter Gutmann in his X.509 Style Guide says this about this
> field : "If you're writing certificate-handling code, just treat the
> serial number as a blob which happens to be an encoded integer".
This is the kind of advice th
Nit: redundant leading 00 (or FF) in an INTEGER is VALID *B*ER
but INVALID *D*ER. And signed things like certs are *D*ER
for exactly this reason, so a reconstructed encoding is
bit for bit identical and hashes and signatures etc. work.
BER is already 'distinguished" concerning the content o
> From: owner-openssl-us...@openssl.org On Behalf Of Peter Sylvester
> Sent: Sunday, 29 August, 2010 05:44
> The encoding is invalid BER.
> The openssl is tolerant but also destructive in copy.
>
> whenever you use openssl x509 -in -out ... you remove one
> leading 0 octet.
>
> IMHO openssl sh
On 08/29/2010 07:38 PM, Mounir IDRASSI wrote:
Hi Peter,
Thank you for your comments.
As I said, this kind of debates can be very heated and going down this
road don't lead usually to any results.
The debate may be whether and how something should be
done in openssl, I admit I had started that
On 08/29/2010 01:20 PM, Mounir IDRASSI wrote:
Hi Peter,
Although the certificate's encoding of the serial number field breaks the
BER specification about the minimal bytes representation, it is known that
many CA's and libraries treat this field as a blob and usually encode it
on a fixed length
gt; downloaded from http://ca.mup.gov.rs/sertifikati-lat.html
>>>
>>> Certificate path is MUPCARoot> MUPCAGradjani and I would like to
>>> validate MUPCAGradjani against the other. What I did is to convert both
>>> to PEM format and rename them by hash as efd6
penssl x509 -in $1 -inform DER -out $hash.0 -outform PEM
Now I run:
$ openssl verify -CApath . efd6650d.0
error 7 at 0 depth lookup:certificate signature failure
16206:error:04077068:rsa routines:RSA_verify:bad
signature:rsa_sign.c:255:
16206:error:0D0C5006:asn1 encoding routin
1 as $hash.0"
openssl x509 -in $1 -inform DER -out $hash.0 -outform PEM
Now I run:
$ openssl verify -CApath . efd6650d.0
error 7 at 0 depth lookup:certificate signature failure
16206:error:04077068:rsa routines:RSA_verify:bad signature:rsa_sign.c:2
ame them by hash as efd6650d.0 (Gradjani) and
fc5fe32d.0 (Root) using this script:
#!/bin/bash
hash=`openssl x509 -in $1 -inform DER -noout -hash`
echo "Saving $1 as $hash.0"
openssl x509 -in $1 -inform DER -out $hash.0 -outform PEM
Now I run:
$ openssl verify -CApath
1 - 100 of 146 matches
Mail list logo
