Re: openssl verify question
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 05 00 04 20, which is missing. I do see this designator with working certificates. I suspect this is the problem. Is that designator mandatory and likely the cause of my issue ? Yes, PKCS#1 signatures must have an algorithm OID prefix. Please beware that a few years ago, I found that a particular Symantec server signedlong term messages (timestamping countersignatures) without that prefix, using animplied algorithm of SHA-1. It may thus be necessary for CMS implementations to accept such signatures for that special case until they naturally expire, and maybe a few years past that. Defining a sufficiently narrow exception is left as an exercise for implementors. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: openssl verify question
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 see this designator with working certificates. I suspect > this is the problem. > > Is that designator mandatory and likely the cause of my issue ? Yes, PKCS#1 signatures must have an algorithm OID prefix. -- Viktor.
Re: openssl verify question
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. $ openssl verify -CAfile rootca.crt server.crt server.crt: C error 7 at 0 depth lookup:certificate signature failure 139734096439184:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1239: 139734096439184:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:405:Type=X509_SIG 139734096439184:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:249: just wondering: why and how are you using an HSM to verify a certificate (without including a private key) ? is the certificate stored only on the HSM? is it possible to get it off the HSM? Also, how are you connecting the HSM to OpenSSL? via opensc-pkcs11 ? you should have an openssl.cnf file somewhere for this. HTH, JJK I tried doing the verification manually like so: Extracting the 'to be signed' part of the server.crt: openssl asn1parse -in server.crt -strparse 4 -out server.tbs sha256 that: cat server.tbs | openssl sha256 -binary > server.tbs.sha256 Extracting the signature from the server.crt: openssl asn1parse -in server.crt -strparse 569 -out server.sig Extracting the public key from rootca.crt: openssl x509 -in rootca.crt -noout -pubkey > rootca.pub Decrypting the signature: openssl rsautl -inkey rootca.pub -pubin -in server.sig -out server.sig.decrypted Comparing server.tbs.sha256 and server.sig.decrypted . 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 see this designator with working certificates. I suspect this is the problem. Is that designator mandatory and likely the cause of my issue ? https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.2 suggests it's mandatory.. but I'm not sure if I'm looking at the right section. Thanks.
openssl verify question
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 server.crt: C error 7 at 0 depth lookup:certificate signature failure 139734096439184:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1239: 139734096439184:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:405:Type=X509_SIG 139734096439184:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:249: I tried doing the verification manually like so: Extracting the 'to be signed' part of the server.crt: openssl asn1parse -in server.crt -strparse 4 -out server.tbs sha256 that: cat server.tbs | openssl sha256 -binary > server.tbs.sha256 Extracting the signature from the server.crt: openssl asn1parse -in server.crt -strparse 569 -out server.sig Extracting the public key from rootca.crt: openssl x509 -in rootca.crt -noout -pubkey > rootca.pub Decrypting the signature: openssl rsautl -inkey rootca.pub -pubin -in server.sig -out server.sig.decrypted Comparing server.tbs.sha256 and server.sig.decrypted . 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 see this designator with working certificates. I suspect this is the problem. Is that designator mandatory and likely the cause of my issue ? https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.1.2 suggests it's mandatory.. but I'm not sure if I'm looking at the right section. Thanks.
