How to Verify AS2 Message (SMIME) Signature With OpenSSL
Learn more about how to verify an AS2 message signature with OpenSSL.
Join the DZone community and get the full member experience.
Join For FreeError MDNs stating an error in the lines of "Signature verification failed" or "Decryption failed" are common for users who are just getting started AS2 in any AS2 service. We, ourselves, have seen many such instances in our SaaS B2B AS2 messaging platform the AdroitLogic AS2Gateway. With these kinds of errors, sometimes, it is important for the support team and also the user itself to be able to try the decryption or signature verification manually to get more insight.
In this blog post, we will look at what the digital signature in AS2 protocol is, how to verify the signature of an AS2 message, and some tips on figuring out the cause for certain signature verification failures.
Signature in AS2 Protocol
AS2 signature is essentially a digital signature that provides authentication, data integrity, and non-repudiation to the AS2 communication.
- Authentication — Ensures that the receiver is transacting with the sender that he/she was meant to transact with (and not an impostor)
- Data Integrity — Determine whether the file or data the receiver got was altered along the way
- Non-Repudiation — Prevent the sender from denying that the messages they sent originated from them
Let's Get to Work!
For demonstration purposes, we will be using an incoming AS2 message to the AS2Gateway, and since we are only focusing on signature verification in this blog post, the incoming AS2 message will is not encrypted or compressed. If you want to try this out with encryption, please take a look at my previous article on decrypting AS2 message with OpenSSL.
Downloading RAW Message and Transport Headers
Once we have received an AS2 message, we can see the received message in the inbox view in AS2Gateway as shown below.
Then, we can click on the message subject (in this case it is "Sample Signed Message") to go to the detailed view of the received message as shown below.
Now, you can click on the "Raw Message" button and "Download Transport Headers" button to download the unprocessed AS2 message payload and transport headers we received from the partner respectively. The raw message will be download to a file with name message.raw and the transport headers will be downloaded to a file with name headers.raw.
Getting the Sender's Public Key
Now that we have the raw message and transport headers, what we need next is the sender's public key, which we can directly download it by clicking the PEM (purple) button from the certificates view (shown below) in the AS2Gateway.
Before we proceed with the next steps, let's make sure we have everything we need in place.
- Raw message (message.raw)
- Transport headers (headers.raw)
- Sender's public key (cert.pem)
Analyzing the HTTP Transport Headers
Let's first take a look at the transport headers before we proceed.
date:Sun, 17 Mar 2019 21:40:01 IST
mime-version:1.0
subject:Sample Signed Message
as2-version:1.2
User-Agent:mendelson opensource AS2 1.1 build 51 - www.mendelson-e-c.com
recipient-address:http://service.as2gateway.org:8280/service/as2-receiver
ediint-features:multiple-attachments, CEM
as2-from:Mendelson_AS2ID
Expect:100-continue
content-disposition:attachment; filename="smime.p7m"
host:service.as2gateway.org:8280
message-id:
disposition-notification-to:http://localhost:8086/as2/HttpReceiver
content-type:multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----=_Part_1_1702144111.1552838995900"
connection:close, TE
from:sender@as2server.com
as2-to:RJ_LOCAL
disposition-notification-options:signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1
Content-Length:2399As you can see, there are a bunch of headers, and thus, let us focus only on a couple of important ones in the context of verifying the signature of the AS2 message.
- The content-type header suggests that we have a multi-part signed payload in the outer most layer and further it tells us that the multi-part boundary is denoted by the string "--=_Part_1_1702144111.1552838995900" for this AS2 message.
- We also have the mime-version to be 1.0
If you are interested in knowing more in-depth details, the best place to start would be the AS2 RFC 4130.
Analyzing the Raw Message
Now, let us look at the raw message (message.raw). As per the content type transport header, we already know that the payload is a multi-part signed one and we can see it below. There you see two parts (separated by the multi-part boundary string as stated in the content-type transport header), one with the original payload (we see the payload in plain text since we did not encrypt or compress the payload for this demonstration) and the other with the signature (application/pkcs7-signature).
------=_Part_1_1702144111.1552838995900
Content-Type: application/EDI-Consent
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=test_message.txt
This is a test message for the demonstration of AS2 signature verification by OpenSSL.
------=_Part_1_1702144111.1552838995900
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggLQMIIC
OQIEQ4798zANBgkqhkiG9w0BAQUFADCBrjEmMCQGCSqGSIb3DQEJARYXcm9zZXR0YW5ldEBtZW5k
ZWxzb24uZGUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEi
MCAGA1UEChMZbWVuZGVsc29uLWUtY29tbWVyY2UgR21iSDEiMCAGA1UECxMZbWVuZGVsc29uLWUt
Y29tbWVyY2UgR21iSDENMAsGA1UEAxMEbWVuZDAeFw0wNTEyMDExMzQzMTVaFw0xOTA4MTAxMzQz
MTVaMIGuMSYwJAYJKoZIhvcNAQkBFhdyb3NldHRhbmV0QG1lbmRlbHNvbi5kZTELMAkGA1UEBhMC
REUxDzANBgNVBAgTBkJlcmxpbjEPMA0GA1UEBxMGQmVybGluMSIwIAYDVQQKExltZW5kZWxzb24t
ZS1jb21tZXJjZSBHbWJIMSIwIAYDVQQLExltZW5kZWxzb24tZS1jb21tZXJjZSBHbWJIMQ0wCwYD
VQQDEwRtZW5kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVBiuTRlvgyx0BuTMV8unaZk6D
ofVmlZGnJ4yb7WjM2KoD/N4M+fOCgASOYNiGlHcEgPVey84D6nOLEflhs5AVnRn5I1VMzFDS0MtB
izKUoGd7KcOvXWI4IHG7bB2QWERnQ0klF1jexL3mIc4oWq92U97JuWsyesFhlb29w3x9QQIDAQAB
MA0GCSqGSIb3DQEBBQUAA4GBAK5xPmuGp6tRM4/JQd/WJryAKSdMzVDIpQBF5LeeYiJi5OwGrG8t
DvaMQUKA5MY/JSr8iWcH3Was1xe6jXVXp4wU1Dn5EPLPrTRczxHgxeGeniO0NB4ytAWT9ttuu3+V
R4b+sD95SCfzaIBOkAu1zDNvURA3F/76FujoCoJmtcFWAAAxggIfMIICGwIBATCBtzCBrjEmMCQG
CSqGSIb3DQEJARYXcm9zZXR0YW5ldEBtZW5kZWxzb24uZGUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQI
EwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEiMCAGA1UEChMZbWVuZGVsc29uLWUtY29tbWVyY2Ug
R21iSDEiMCAGA1UECxMZbWVuZGVsc29uLWUtY29tbWVyY2UgR21iSDENMAsGA1UEAxMEbWVuZAIE
Q4798zAJBgUrDgMCGgUAoIG+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTE5MDMxNzE2MTAwMFowIwYJKoZIhvcNAQkEMRYEFHJyF4g/r57EXS/lc75lHLg7NlPFMCkG
CSqGSIb3DQEJNDEcMBowCQYFKw4DAhoFAKENBgkqhkiG9w0BAQEFADA0BgkqhkiG9w0BCQ8xJzAl
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBgkqhkiG9w0BAQEFAASBgEoT
cuU4zywEzmQW95i+Deh3GT1280BYG1L3JuMtos7wgYTn5SHu+uk3LbCgLcDI9CNoiuYx4gRqlMaH
jy9stQLpljZyOSZoP7Md0NsZpq5DtNEgBm77FKsko+y8KvcLBrIGSR8oQpvpDP2siiU8vNxB9nwQ
W7UJSi6l22MJisu3AAAAAAAA
------=_Part_1_1702144111.1552838995900--Adding Required Headers
Do you remember that we talked about a few important transport headers when we looking at the transport headers? Now is the time to use them. We need to add those headers to our message.raw file so that the final output would be as follows. (Let's take the new file as message_with_headers.raw) Note that the white space between the HTTP transport headers and the multi-part signed payload is intentional.
mime-version:1.0
content-type:multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----=_Part_1_1702144111.1552838995900"
------=_Part_1_1702144111.1552838995900
Content-Type: application/EDI-Consent
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=test_message.txt
This is a test message for the demonstration of AS2 signature verification by OpenSSL.
------=_Part_1_1702144111.1552838995900
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggLQMIIC
OQIEQ4798zANBgkqhkiG9w0BAQUFADCBrjEmMCQGCSqGSIb3DQEJARYXcm9zZXR0YW5ldEBtZW5k
ZWxzb24uZGUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEi
MCAGA1UEChMZbWVuZGVsc29uLWUtY29tbWVyY2UgR21iSDEiMCAGA1UECxMZbWVuZGVsc29uLWUt
Y29tbWVyY2UgR21iSDENMAsGA1UEAxMEbWVuZDAeFw0wNTEyMDExMzQzMTVaFw0xOTA4MTAxMzQz
MTVaMIGuMSYwJAYJKoZIhvcNAQkBFhdyb3NldHRhbmV0QG1lbmRlbHNvbi5kZTELMAkGA1UEBhMC
REUxDzANBgNVBAgTBkJlcmxpbjEPMA0GA1UEBxMGQmVybGluMSIwIAYDVQQKExltZW5kZWxzb24t
ZS1jb21tZXJjZSBHbWJIMSIwIAYDVQQLExltZW5kZWxzb24tZS1jb21tZXJjZSBHbWJIMQ0wCwYD
VQQDEwRtZW5kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVBiuTRlvgyx0BuTMV8unaZk6D
ofVmlZGnJ4yb7WjM2KoD/N4M+fOCgASOYNiGlHcEgPVey84D6nOLEflhs5AVnRn5I1VMzFDS0MtB
izKUoGd7KcOvXWI4IHG7bB2QWERnQ0klF1jexL3mIc4oWq92U97JuWsyesFhlb29w3x9QQIDAQAB
MA0GCSqGSIb3DQEBBQUAA4GBAK5xPmuGp6tRM4/JQd/WJryAKSdMzVDIpQBF5LeeYiJi5OwGrG8t
DvaMQUKA5MY/JSr8iWcH3Was1xe6jXVXp4wU1Dn5EPLPrTRczxHgxeGeniO0NB4ytAWT9ttuu3+V
R4b+sD95SCfzaIBOkAu1zDNvURA3F/76FujoCoJmtcFWAAAxggIfMIICGwIBATCBtzCBrjEmMCQG
CSqGSIb3DQEJARYXcm9zZXR0YW5ldEBtZW5kZWxzb24uZGUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQI
EwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEiMCAGA1UEChMZbWVuZGVsc29uLWUtY29tbWVyY2Ug
R21iSDEiMCAGA1UECxMZbWVuZGVsc29uLWUtY29tbWVyY2UgR21iSDENMAsGA1UEAxMEbWVuZAIE
Q4798zAJBgUrDgMCGgUAoIG+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTE5MDMxNzE2MTAwMFowIwYJKoZIhvcNAQkEMRYEFHJyF4g/r57EXS/lc75lHLg7NlPFMCkG
CSqGSIb3DQEJNDEcMBowCQYFKw4DAhoFAKENBgkqhkiG9w0BAQEFADA0BgkqhkiG9w0BCQ8xJzAl
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBgkqhkiG9w0BAQEFAASBgEoT
cuU4zywEzmQW95i+Deh3GT1280BYG1L3JuMtos7wgYTn5SHu+uk3LbCgLcDI9CNoiuYx4gRqlMaH
jy9stQLpljZyOSZoP7Md0NsZpq5DtNEgBm77FKsko+y8KvcLBrIGSR8oQpvpDP2siiU8vNxB9nwQ
W7UJSi6l22MJisu3AAAAAAAA
------=_Part_1_1702144111.1552838995900--Verifying the Signature...
It's time to run the decryption command. Here, we use the smime tool by OpenSSL.
openssl smime -verify -noverify -in message_with_headers.raw -signer cert.pem -out verified_payload.txtOnce you run the command, you should get a message saying "Verification successful" and the verified payload would be in the file verified_payload.txt. Note that, in this case, we will get the payload mime part as the output, which would look something as follows.
Content-Type: application/EDI-Consent
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=test_message.txt
This is a test message for the demonstration of AS2 signature verification by OpenSSL.Just for completion, let me add a note on an error I got while trying this. For me, the cause for this error was a mismatch in the multi-part boundary string in the content-type header with actual multi-part boundary string. Note that there are two preceding '-'s are there when the multi-part boundary is used in a multi-part SMIME payload.
Error reading S/MIME message
4719224428:error:0DFFF0D2:asn1 encoding routines:CRYPTO_internal:no multipart body failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.240.1/libressl-2.6/crypto/asn1/asn_mime.c:464:Further note that we have used the parameter -noverify in the signature verification command. This is because the certificates we have used in this demo are self-signed certificates and if the noverifyparam is not used, OpenSSL will try to verify the certificate first and will fail giving an error similar to following.
Verification failure
4567594604:error:21FFF075:PKCS7 routines:func(4095):certificate verify error:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.240.1/libressl-2.6/crypto/pkcs7/pk7_smime.c:340:Verify error:self signed certificateCool. Signature verification is done and dusted. Even though we've looked at doing the signature verification entirely using command line tools in this article, this can be done using a few lines on Java code as well. I hope to cover it in a future article.
Bonus Pack
Before signing off, I would like to share some bonus details which would help you identify the cause for certain signature verification failure scenarios. The first one is on how to find out the signature algorithm used.
Finding Out the Signature Algorithm Used
In order to find the signature algorithm used, we can use a the asn1parse tool by OpenSSL but first, we need to separate out the signature part without the mime headers to a separate file as follows. Let's call this file as signature.raw:
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggLQMIIC
OQIEQ4798zANBgkqhkiG9w0BAQUFADCBrjEmMCQGCSqGSIb3DQEJARYXcm9zZXR0YW5ldEBtZW5k
ZWxzb24uZGUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQIEwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEi
MCAGA1UEChMZbWVuZGVsc29uLWUtY29tbWVyY2UgR21iSDEiMCAGA1UECxMZbWVuZGVsc29uLWUt
Y29tbWVyY2UgR21iSDENMAsGA1UEAxMEbWVuZDAeFw0wNTEyMDExMzQzMTVaFw0xOTA4MTAxMzQz
MTVaMIGuMSYwJAYJKoZIhvcNAQkBFhdyb3NldHRhbmV0QG1lbmRlbHNvbi5kZTELMAkGA1UEBhMC
REUxDzANBgNVBAgTBkJlcmxpbjEPMA0GA1UEBxMGQmVybGluMSIwIAYDVQQKExltZW5kZWxzb24t
ZS1jb21tZXJjZSBHbWJIMSIwIAYDVQQLExltZW5kZWxzb24tZS1jb21tZXJjZSBHbWJIMQ0wCwYD
VQQDEwRtZW5kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVBiuTRlvgyx0BuTMV8unaZk6D
ofVmlZGnJ4yb7WjM2KoD/N4M+fOCgASOYNiGlHcEgPVey84D6nOLEflhs5AVnRn5I1VMzFDS0MtB
izKUoGd7KcOvXWI4IHG7bB2QWERnQ0klF1jexL3mIc4oWq92U97JuWsyesFhlb29w3x9QQIDAQAB
MA0GCSqGSIb3DQEBBQUAA4GBAK5xPmuGp6tRM4/JQd/WJryAKSdMzVDIpQBF5LeeYiJi5OwGrG8t
DvaMQUKA5MY/JSr8iWcH3Was1xe6jXVXp4wU1Dn5EPLPrTRczxHgxeGeniO0NB4ytAWT9ttuu3+V
R4b+sD95SCfzaIBOkAu1zDNvURA3F/76FujoCoJmtcFWAAAxggIfMIICGwIBATCBtzCBrjEmMCQG
CSqGSIb3DQEJARYXcm9zZXR0YW5ldEBtZW5kZWxzb24uZGUxCzAJBgNVBAYTAkRFMQ8wDQYDVQQI
EwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEiMCAGA1UEChMZbWVuZGVsc29uLWUtY29tbWVyY2Ug
R21iSDEiMCAGA1UECxMZbWVuZGVsc29uLWUtY29tbWVyY2UgR21iSDENMAsGA1UEAxMEbWVuZAIE
Q4798zAJBgUrDgMCGgUAoIG+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTE5MDMxNzE2MTAwMFowIwYJKoZIhvcNAQkEMRYEFHJyF4g/r57EXS/lc75lHLg7NlPFMCkG
CSqGSIb3DQEJNDEcMBowCQYFKw4DAhoFAKENBgkqhkiG9w0BAQEFADA0BgkqhkiG9w0BCQ8xJzAl
MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBgkqhkiG9w0BAQEFAASBgEoT
cuU4zywEzmQW95i+Deh3GT1280BYG1L3JuMtos7wgYTn5SHu+uk3LbCgLcDI9CNoiuYx4gRqlMaH
jy9stQLpljZyOSZoP7Md0NsZpq5DtNEgBm77FKsko+y8KvcLBrIGSR8oQpvpDP2siiU8vNxB9nwQ
W7UJSi6l22MJisu3AAAAAAAANow, we can run the following command to get the asn1parse output.
openssl asn1parse -i -in signature.rawThe output would be as follows. If you can see below, the outer most part has type pkcs7-signedData and after four or five lines we see sha1, which is the signature algorithm used.
0:d=0 hl=2 l=inf cons: SEQUENCE
2:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
13:d=1 hl=2 l=inf cons: cont [ 0 ]
15:d=2 hl=2 l=inf cons: SEQUENCE
17:d=3 hl=2 l= 1 prim: INTEGER :01
20:d=3 hl=2 l= 11 cons: SET
22:d=4 hl=2 l= 9 cons: SEQUENCE
24:d=5 hl=2 l= 5 prim: OBJECT :sha1
31:d=5 hl=2 l= 0 prim: NULL
33:d=3 hl=2 l=inf cons: SEQUENCE
35:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
46:d=4 hl=2 l= 0 prim: EOC
48:d=3 hl=2 l=inf cons: cont [ 0 ]
50:d=4 hl=4 l= 720 cons: SEQUENCE
54:d=5 hl=4 l= 569 cons: SEQUENCE
58:d=6 hl=2 l= 4 prim: INTEGER :438EFDF3
64:d=6 hl=2 l= 13 cons: SEQUENCE
66:d=7 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
77:d=7 hl=2 l= 0 prim: NULL
79:d=6 hl=3 l= 174 cons: SEQUENCE
82:d=7 hl=2 l= 38 cons: SET
84:d=8 hl=2 l= 36 cons: SEQUENCE
86:d=9 hl=2 l= 9 prim: OBJECT :emailAddress
97:d=9 hl=2 l= 23 prim: IA5STRING :rosettanet@mendelson.de
122:d=7 hl=2 l= 11 cons: SET
124:d=8 hl=2 l= 9 cons: SEQUENCE
126:d=9 hl=2 l= 3 prim: OBJECT :countryName
131:d=9 hl=2 l= 2 prim: PRINTABLESTRING :DE
135:d=7 hl=2 l= 15 cons: SET
137:d=8 hl=2 l= 13 cons: SEQUENCE
139:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
144:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Berlin
152:d=7 hl=2 l= 15 cons: SET
154:d=8 hl=2 l= 13 cons: SEQUENCE
156:d=9 hl=2 l= 3 prim: OBJECT :localityName
161:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Berlin
169:d=7 hl=2 l= 34 cons: SET
171:d=8 hl=2 l= 32 cons: SEQUENCE
173:d=9 hl=2 l= 3 prim: OBJECT :organizationName
178:d=9 hl=2 l= 25 prim: PRINTABLESTRING :mendelson-e-commerce GmbH
205:d=7 hl=2 l= 34 cons: SET
207:d=8 hl=2 l= 32 cons: SEQUENCE
209:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
214:d=9 hl=2 l= 25 prim: PRINTABLESTRING :mendelson-e-commerce GmbH
241:d=7 hl=2 l= 13 cons: SET
243:d=8 hl=2 l= 11 cons: SEQUENCE
245:d=9 hl=2 l= 3 prim: OBJECT :commonName
250:d=9 hl=2 l= 4 prim: PRINTABLESTRING :mend
256:d=6 hl=2 l= 30 cons: SEQUENCE
258:d=7 hl=2 l= 13 prim: UTCTIME :051201134315Z
273:d=7 hl=2 l= 13 prim: UTCTIME :190810134315Z
288:d=6 hl=3 l= 174 cons: SEQUENCE
291:d=7 hl=2 l= 38 cons: SET
293:d=8 hl=2 l= 36 cons: SEQUENCE
295:d=9 hl=2 l= 9 prim: OBJECT :emailAddress
306:d=9 hl=2 l= 23 prim: IA5STRING :rosettanet@mendelson.de
331:d=7 hl=2 l= 11 cons: SET
333:d=8 hl=2 l= 9 cons: SEQUENCE
335:d=9 hl=2 l= 3 prim: OBJECT :countryName
340:d=9 hl=2 l= 2 prim: PRINTABLESTRING :DE
344:d=7 hl=2 l= 15 cons: SET
346:d=8 hl=2 l= 13 cons: SEQUENCE
348:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
353:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Berlin
361:d=7 hl=2 l= 15 cons: SET
363:d=8 hl=2 l= 13 cons: SEQUENCE
365:d=9 hl=2 l= 3 prim: OBJECT :localityName
370:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Berlin
378:d=7 hl=2 l= 34 cons: SET
380:d=8 hl=2 l= 32 cons: SEQUENCE
382:d=9 hl=2 l= 3 prim: OBJECT :organizationName
387:d=9 hl=2 l= 25 prim: PRINTABLESTRING :mendelson-e-commerce GmbH
414:d=7 hl=2 l= 34 cons: SET
416:d=8 hl=2 l= 32 cons: SEQUENCE
418:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
423:d=9 hl=2 l= 25 prim: PRINTABLESTRING :mendelson-e-commerce GmbH
450:d=7 hl=2 l= 13 cons: SET
452:d=8 hl=2 l= 11 cons: SEQUENCE
454:d=9 hl=2 l= 3 prim: OBJECT :commonName
459:d=9 hl=2 l= 4 prim: PRINTABLESTRING :mend
465:d=6 hl=3 l= 159 cons: SEQUENCE
468:d=7 hl=2 l= 13 cons: SEQUENCE
470:d=8 hl=2 l= 9 prim: OBJECT :rsaEncryption
481:d=8 hl=2 l= 0 prim: NULL
483:d=7 hl=3 l= 141 prim: BIT STRING
627:d=5 hl=2 l= 13 cons: SEQUENCE
629:d=6 hl=2 l= 9 prim: OBJECT :sha1WithRSAEncryption
640:d=6 hl=2 l= 0 prim: NULL
642:d=5 hl=3 l= 129 prim: BIT STRING
774:d=4 hl=2 l= 0 prim: EOC
776:d=3 hl=4 l= 543 cons: SET
780:d=4 hl=4 l= 539 cons: SEQUENCE
784:d=5 hl=2 l= 1 prim: INTEGER :01
787:d=5 hl=3 l= 183 cons: SEQUENCE
790:d=6 hl=3 l= 174 cons: SEQUENCE
793:d=7 hl=2 l= 38 cons: SET
795:d=8 hl=2 l= 36 cons: SEQUENCE
797:d=9 hl=2 l= 9 prim: OBJECT :emailAddress
808:d=9 hl=2 l= 23 prim: IA5STRING :rosettanet@mendelson.de
833:d=7 hl=2 l= 11 cons: SET
835:d=8 hl=2 l= 9 cons: SEQUENCE
837:d=9 hl=2 l= 3 prim: OBJECT :countryName
842:d=9 hl=2 l= 2 prim: PRINTABLESTRING :DE
846:d=7 hl=2 l= 15 cons: SET
848:d=8 hl=2 l= 13 cons: SEQUENCE
850:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
855:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Berlin
863:d=7 hl=2 l= 15 cons: SET
865:d=8 hl=2 l= 13 cons: SEQUENCE
867:d=9 hl=2 l= 3 prim: OBJECT :localityName
872:d=9 hl=2 l= 6 prim: PRINTABLESTRING :Berlin
880:d=7 hl=2 l= 34 cons: SET
882:d=8 hl=2 l= 32 cons: SEQUENCE
884:d=9 hl=2 l= 3 prim: OBJECT :organizationName
889:d=9 hl=2 l= 25 prim: PRINTABLESTRING :mendelson-e-commerce GmbH
916:d=7 hl=2 l= 34 cons: SET
918:d=8 hl=2 l= 32 cons: SEQUENCE
920:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
925:d=9 hl=2 l= 25 prim: PRINTABLESTRING :mendelson-e-commerce GmbH
952:d=7 hl=2 l= 13 cons: SET
954:d=8 hl=2 l= 11 cons: SEQUENCE
956:d=9 hl=2 l= 3 prim: OBJECT :commonName
961:d=9 hl=2 l= 4 prim: PRINTABLESTRING :mend
967:d=6 hl=2 l= 4 prim: INTEGER :438EFDF3
973:d=5 hl=2 l= 9 cons: SEQUENCE
975:d=6 hl=2 l= 5 prim: OBJECT :sha1
982:d=6 hl=2 l= 0 prim: NULL
984:d=5 hl=3 l= 190 cons: cont [ 0 ]
987:d=6 hl=2 l= 24 cons: SEQUENCE
989:d=7 hl=2 l= 9 prim: OBJECT :contentType
1000:d=7 hl=2 l= 11 cons: SET
1002:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
1013:d=6 hl=2 l= 28 cons: SEQUENCE
1015:d=7 hl=2 l= 9 prim: OBJECT :signingTime
1026:d=7 hl=2 l= 15 cons: SET
1028:d=8 hl=2 l= 13 prim: UTCTIME :190317161000Z
1043:d=6 hl=2 l= 35 cons: SEQUENCE
1045:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
1056:d=7 hl=2 l= 22 cons: SET
1058:d=8 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:727217883FAF9EC45D2FE573BE651CB83B3653C5
1080:d=6 hl=2 l= 41 cons: SEQUENCE
1082:d=7 hl=2 l= 9 prim: OBJECT :1.2.840.113549.1.9.52
1093:d=7 hl=2 l= 28 cons: SET
1095:d=8 hl=2 l= 26 cons: SEQUENCE
1097:d=9 hl=2 l= 9 cons: SEQUENCE
1099:d=10 hl=2 l= 5 prim: OBJECT :sha1
1106:d=10 hl=2 l= 0 prim: NULL
1108:d=9 hl=2 l= 13 cons: cont [ 1 ]
1110:d=10 hl=2 l= 9 prim: OBJECT :rsaEncryption
1121:d=10 hl=2 l= 0 prim: NULL
1123:d=6 hl=2 l= 52 cons: SEQUENCE
1125:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities
1136:d=7 hl=2 l= 39 cons: SET
1138:d=8 hl=2 l= 37 cons: SEQUENCE
1140:d=9 hl=2 l= 10 cons: SEQUENCE
1142:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
1152:d=9 hl=2 l= 14 cons: SEQUENCE
1154:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc
1164:d=10 hl=2 l= 2 prim: INTEGER :80
1168:d=9 hl=2 l= 7 cons: SEQUENCE
1170:d=10 hl=2 l= 5 prim: OBJECT :des-cbc
1177:d=5 hl=2 l= 13 cons: SEQUENCE
1179:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
1190:d=6 hl=2 l= 0 prim: NULL
1192:d=5 hl=3 l= 128 prim: OCTET STRING [HEX DUMP]:4A1372E538CF2C04CE6416F798BE0DE877193D76F340581B52F726E32DA2CEF08184E7E521EEFAE9372DB0A02DC0C8F423688AE631E2046A94C6878F2F6CB502E99636723926683FB31DD0DB19A6AE43B4D120066EFB14AB24A3ECBC2AF70B06B206491F28429BE90CFDAC8A253CBCDC41F67C105BB5094A2EA5DB63098ACBB7
1323:d=3 hl=2 l= 0 prim: EOC
1325:d=2 hl=2 l= 0 prim: EOC
1327:d=1 hl=2 l= 0 prim: EOCMore Details From the ASN1Parse Output
There are a few more details we can see and understand from the asn1parse output. Optionally, when signing, the signing certificates are attached to the signature itself. That is what you see starting from the pkcs7-data section. The INTEGER : 438EFDF3 is the signing cert serial number. You can also see the validation period of the certificate as shown below:
258:d=7 hl=2 l= 13 prim: UTCTIME :051201134315Z
273:d=7 hl=2 l= 13 prim: UTCTIME :190810134315Z
Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. Agents MUST interpret the year field (YY) as follows: if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY.
Regarding UTCTime from RFC 2311 - https://tools.ietf.org/html/rfc2311
In this case, the period in which the certificate is valid is from UTC 2005/12/01 13:43:15 to 2019/08/10 13:43:15.
We also have the signing time at signingTime attribute as 190317161000Z, which is UTC 2019/03/17 16:10:00. Note that during signature validation, in addition to the content hash matching, another check will be made to see if the signature was when the certificate was current. Basically, at the time of the signing, the certificate should be valid.
With some more knowledge in ASN.1 structure, we should be able to gain a lot more information from this. It's time for me to sign off. Cheers!
Call to Action
- Like. Share. Appreciate and let others find this article.
- Comment. Share your views on this article.
- Keep in touch. LinkedIn, Twitter
Originally published at notebookbft.wordpress.com on March 19, 2019.
Published at DZone with permission of Rajind Ruparathna, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments