0

I need to (write a program to) verify signature in a (bunch of) signed XML files.

NOTE: I am dealing with XML files signed according to 'http://www.w3.org/TR/2001/REC-xml-c14n-20010315', not just plain file signature; openssl digest is not enough.

NOTE: This is a CUSTOM-CA, so I need to use some pre-shared certificate for validation, I cannot rely on the standard CA-lists.

The signing CA is custom and I've been given several "certificates", in various forms, some of which pertaining to "testing environment" and "production environment.

Communicating with the CA (a government agency) is "somewhat difficult".

I really need is to understand how to interpret "openssl x509" output (or some other means) in order to reconstruct chain of trust and find out which certificate (if any) can be used to verify the one sent together with signature.

NOTE: My main difficulty is to understand WHICH, of the certificates I own, I should use and HOW, so I need to reverse-engineer what I have. OF COURSE, it would be much better to get the information directly from the CA, but if You think it's easy to get technical information from the Italian Tax Agency You're welcome to try :(

If deemed useful I can post an example answer and/or the (public) certificates I've been given.

I would like to be able to manually (via command-line tools) verify a signature, then I should be able to automate the process.

NOTE: my real question is: Given a bunch of of certificates and a bunch of "known good" answers (signed XML) how can I divine which certificate(s) I have to use to validate next answer?

Answer contains two certificates and a signature; IFF I understand it correctly I should use one of the certificates included in the answer to validate the signature and thus the signed message. Remaining step is to validate the certificate itself with one of the certificates "pre-shared" I own. To date I failed last step.

UPDATE: Here follows an example answer, containing the certificate I use to validate itself. This certificate has a:

X509v3 Authority Key Identifier: 
    keyid:22:FD:AA:69:22:4C:9C:B1:20:62:9D:32:C7:D5:17:5B:EA:9C:C1:33

matching:

X509v3 Subject Key Identifier: 
    22:FD:AA:69:22:4C:9C:B1:20:62:9D:32:C7:D5:17:5B:EA:9C:C1:33

on the "supposedly right" certificate. Where can I find information about the exact meaning and usage of those fields (and their siblings)?.

Example answer (test environment):

<?xml version="1.0" encoding="UTF-8"?>
<p:EsitoOperazione xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:p="http://ivaservizi.agenziaentrate.gov.it/docs/xsd/corrispettivi/v1.0" versione="1.0"><IdOperazione>DP2220925789</IdOperazione><Errori><Errore><Codice>00000</Codice><Descrizione>XML non conforme al tracciato</Descrizione></Errore></Errori><Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
  <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
  <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
  <Reference URI="">
    <Transforms>
      <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
      <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    </Transforms>
    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
    <DigestValue>lDvi4e+cWIGVQl9+4yf6FBTIuS/yPvGoZr9vVktfUg8=</DigestValue>
  </Reference>
</SignedInfo>
    <SignatureValue>Pyf3ZgznAGO+Sq3VjoSMBSGE8iZbNZubmc7qLbqAQ4T7h9zOcEm1S5KU3Z52TzjX0YsOnwoFu5lrThIdmO53YpR42nHTxqA6fX8YtfeX9mPnRU6WCcgIB0z507oPx8mky7IsAe3J0FhzfcJwMjJK1h0OSr3EFEMDOTh62f18UumCeY900HbcqenfyCamULjkQKQ+ts2AhESyBQMd/9VLfknMYN5PN6XIhh2VQKXjJtpp+bKUlxKMQGjl65DzGHAhXg0YppxOmdTjvrJNXTt0WZ8hopTQGRJeWoEj0/no9NPRsMammUEYH8OejcvqsxeqU1RAD4mlDZf0G5+WdEGGXw==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIEeDCCA2CgAwIBAgIIIyLY5OxLz9cwDQYJKoZIhvcNAQELBQAwcjELMAkGA1UEBhMCaXQxHjAcBgNVBAoTFUFnZW56aWEgZGVsbGUgRW50cmF0ZTEbMBkGA1UECxMSU2Vydml6aSBUZWxlbWF0aWNpMSYwJAYDVQQDEx1DQSBBZ2VuemlhIGRlbGxlIEVudHJhdGUgVGVzdDAeFw0xNjA2MDEwOTI4MDFaFw0xOTA2MDIwOTI4MDFaMHIxCzAJBgNVBAYTAklUMRswGQYDVQQKDBJTZXJ2aXppIFRlbGVtYXRpY2kxHjAcBgNVBAsMFUFnZW56aWEgZGVsbGUgRW50cmF0ZTEmMCQGA1UEAwwdU2Vydml6aW8gQUUgQ29ycmlzcGV0dGl2aSBJVkEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCDTgNdGUfbC0Pv2n5DGADue0a63FeWPH0TM5Ulvt46Q4Hy561hzOJiXNsdXNvKQJUUisK/lwbJ8ZeXk7atHywvVvn9hk7CUnBz+O7J0VANwBfebaPYtvElV5MElf2Bkb+Fxwa9A8mIGHNj4p3QOXldzQZBt6XQuWayDtVS91F8n5NeBR+1xyg3D0zvdDXvJ+0Ct6r0dfiddNlU1bJmVlHrWjQRR9Tz0p35j7A8bEe7pIuwZa4Szv4tQwzV+QHLqfsQfpIG5SheSA7o43EaC5xs3K5kinWd2MhSHJl8+t/4zbhVkLTD2HPoRYh+tYuO9pzmvOmbXidX+mHeza6PksYFAgMBAAGjggEQMIIBDDAdBgNVHQ4EFgQUjiotXv6kt2P0jCvqVMo1iTakFTcwHwYDVR0jBBgwFoAUIv2qaSJMnLEgYp0yx9UXW+qcwTMwgbkGA1UdHwSBsTCBrjCBq6CBqKCBpYaBomxkYXA6Ly9jYWRzLmVudHJhdGUuZmluYW56ZS5pdC9jbiUzZENBJTIwQWdlbnppYSUyMGRlbGxlJTIwRW50cmF0ZSUyMFRlc3Qsb3UlM2RTZXJ2aXppJTIwVGVsZW1hdGljaSxvJTNkQWdlbnppYSUyMGRlbGxlJTIwRW50cmF0ZSxjJTNkaXQ/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDAOBgNVHQ8BAf8EBAMCBkAwDQYJKoZIhvcNAQELBQADggEBAKbnawkys14e8mQb7PXFFoy3UQ1z6H9/iQlQLidkDxEpKFfW+cCI3VpA9hPwSD0mJqVwW15QpkGKvYdGh2mQMFSQxl2Pa28Z20s823VnnAeCKwcNMd6nqzJzqRyVIMQcfOh6DCunr8EyItc36DOG098l9olCYhURLUwFDUwoAoX1yBAetbaWR0TNFDpWZn6JfrWqHkBGaMdhBM+6ANpIcNSJXcj67u5FmtjDVxG1PedDd1McZsGo7pE7vT+118gqhNSeYFbLUWhhXQLdjq3Gq95UWBlPeq9rfteBmkt4fP8OZebdA2IQVhqFv9muVelfbxex8GSd0UQhD2FppQ5ZSJg=</X509Certificate><X509IssuerSerial><X509IssuerName>CN=CA Agenzia delle Entrate Test, OU=Servizi Telematici, O=Agenzia delle Entrate, C=it</X509IssuerName><X509SerialNumber>2531824418264174551</X509SerialNumber></X509IssuerSerial></X509Data></KeyInfo></Signature></p:EsitoOperazione>

Test environment public certificate:

-----BEGIN CERTIFICATE-----
MIIEXDCCA0SgAwIBAgICG/4wDQYJKoZIhvcNAQEFBQAwcjELMAkGA1UEBhMCaXQx
HjAcBgNVBAoTFUFnZW56aWEgZGVsbGUgRW50cmF0ZTEbMBkGA1UECxMSU2Vydml6
aSBUZWxlbWF0aWNpMSYwJAYDVQQDEx1DQSBBZ2VuemlhIGRlbGxlIEVudHJhdGUg
VGVzdDAeFw0xMDEyMDYxNTIyNDVaFw0yMDEyMDYxNTIxNTJaMHIxCzAJBgNVBAYT
Aml0MR4wHAYDVQQKExVBZ2VuemlhIGRlbGxlIEVudHJhdGUxGzAZBgNVBAsTElNl
cnZpemkgVGVsZW1hdGljaTEmMCQGA1UEAxMdQ0EgQWdlbnppYSBkZWxsZSBFbnRy
YXRlIFRlc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyvPxOwNmm
6yk5B1shFEd8EDf+CkeRVOQ3lOiW1wsGnBz7o0ASah3XeaguNxs2ZDe/xmfgPwuF
8Jwtcoz/YkWCEfuQL4kpA5Wm4fMaXewQjTb50RvuNOdPdSqFCqpYdKzQbXvKrcJo
KFXxZy28eLam59iVUbR5U9Uh3kzp8NhfKblNbAE9fz7jIiIJssxhOrFtawOhtDrq
H9uwKpoUlbqlSgpUd1XKCPzD+odnqx0S1PtRDdZxHvzHHl89WNAIk88bP6YhHQBP
MjrOi7VxiWv56pr2+fKheE0GeKKgKS0VwLYWCPpEb3X32uMdIJxue4z7MRxbbmh2
vTJzFCNpIuJNAgMBAAGjgfswgfgwEgYDVR0TAQH/BAgwBgEB/wIBAzCBsgYDVR0f
BIGqMIGnMIGkoIGhoIGehoGbbGRhcDovL2NhZHMuZW50cmF0ZS5maW5hbnplLml0
L2NuJTNkQ0ElMjBBZ2VuemlhJTIwZGVsbGUlMjBFbnRyYXRlLG91JTNkU2Vydml6
aSUyMFRlbGVtYXRpY2ksbyUzZEFnZW56aWElMjBkZWxsZSUyMEVudHJhdGUsYyUz
ZGl0P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3QwDgYDVR0PAQH/BAQDAgEGMB0G
A1UdDgQWBBQi/appIkycsSBinTLH1Rdb6pzBMzANBgkqhkiG9w0BAQUFAAOCAQEA
C/zKId0jP7Jr3HhKXhpIWrPUtswf+Hg3iJIJe3jpdloWbShnNaP01OuPNgz7ovcC
RGOSGRFyvkfDl8sbt8QoyHOHH8wkZWZ0EZixIgrFRtoan+2pzx5ttljgEAz3z/J9
WZQpQXmvcXcHZomrHorVSv1t6cDMiFqLtawD9gOQBAx7s4rke04DABWguAK0Efuu
dB5B5dJGuxrdh8erOs/FICdrY9K0N5tudxFGRcnZHKGvdR+ydRSoFbCp8mZyNers
rTTVbVQJ6gaWVEW6BJRg583Gt8btxqyHABodRmRnSXJ+BAQ68JoCTLETkskpl+Vu
5/wNrq+E/k4g3qB/6OTWBA==
-----END CERTIFICATE-----

AGAIN, PRETTY PLEASE: I want to understand how to interpret and decode the certificate chain, not just to test if they match. Any pointer to (relevant) documentation is welcome. Up to now I only found either very high level descriptions or finest-grade specifications which are hard to digest without previous knowledge (let alone drowning in thousands of pages).

Improve this question
1

1 Answer 1

Reset to default
0

Inputs you will need:

  • the file (data) you want to verify
  • the byte array (probably base64 ecnoded) of the signature
  • the public key of the signer (you can extract this from a certificate)

Code (source):

openssl base64 -d -in $signature -out /tmp/$filename.sha256
openssl dgst -sha256 -verify $publickey -signature /tmp/$filename.sha256 $filename
rm /tmp/$filename.sha256
Improve this answer
7
  • 1
    AND the public key of the trusted CA (or CA-s, you can have multiple trust roots). Not only do you verify the file signature, you have to verify that the signer's key was issued from a trusted chain (the whole cert chain is anchored by one of the trusted roots). Otherwise you've verified the signature, but not that it is a trusted signature
    – Ruscal
    Jan 10, 2019 at 19:13
  • @Ruscal: that is exactly the point. As detailed in my revision of Q, my main problem is to sort out which certificate I should use to validate the certificate coming with the request. I didn't find any detailed description for the output of `openssl x509 -in xxx.cer -noout -text". I will further update my Question.
    – ZioByte
    Jan 11, 2019 at 9:17
  • @ZioByte it sounds like you need to look at the chaining concept. Each certificate has a Subject Name and an Issued By field. For the root certificate, those will be the same (a trusted root CA issues its own cert). Then the chain continues, each intermediate certificate is "Issued By" the "Subject Name" of the proceeding certificate. Until you get to the end, the last cert in the chain is still issued by the proceeding, but nothing is left to be issued by it. That last cert is the one that was used to sign. Check validity of root, check signature via last.
    – Ruscal
    Jan 11, 2019 at 14:45
  • @Ruscal: Thanks. That is the kind of information I was fishing for. Anyways "Issuer" and "Subject" are essentially the "-subj" used when generating the CSR (and thus could be duplicated). Is there a way to do the same walking using Key Identifiers (or equivalent signatures)?
    – ZioByte
    Jan 12, 2019 at 10:30
  • No. But this is why trusted root lists exist. Sure anyone can write anything for their issuer value, but you have a list of trusted issuers and their public key; make sure the issuer is on your list and the key matches. You should read up on certificate verification, this is in the standard. Once you have a good root, the issuer signs each certificate it produces. So each parent in the chain can be used to verify the child is trusted by that parent. All the way back to a trusted root.
    – Ruscal
    Jan 12, 2019 at 15:52

Not the answer you're looking for? Browse other questions tagged .