How to Verify AS2 Message (SMIME) Signature With OpenSSL

Learn more about how to verify an AS2 message signature with OpenSSL.

Rajind Ruparathna

Updated May. 02, 19 · Tutorial

Likes (4)

Comment

Save

10.3K Views

Error 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

As shown in the above figure, the sender's private key is used when generating the signature and thus for verification sender's public key is used.

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:2399

As 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.txt

Once 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 certificate

Cool. 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
W7UJSi6l22MJisu3AAAAAAAA

Now, we can run the following command to get the asn1parse output.

openssl asn1parse -i -in signature.raw

The 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:  EOC

More 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.

Featured image by ar130405 on PixaBay.

AS2 OpenSSL Payload (computing)

Published at DZone with permission of Rajind Ruparathna, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

Trending