I am adding an object to a bucket in Amazon S3. The addition is successful, now I want to make the file accessible to others by the pre-signed url.
The pre-signed url is of the form:
https://<bucket>.s3.amazonaws.com/<key>?AWSAccessKeyId=<access key>&Expires=1432722343&Signature=mmfv%2Fddhhakla1csUrb%2FtRCXYu8%3D
But when I try to load the url, it return with an error:
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>
The request signature we calculated does not match the signature you provided. Check your key and signing method.
</Message>
<AWSAccessKeyId></AWSAccessKeyId>
<StringToSign>
GET 1432727995 /<bucket>/<key>
</StringToSign>
<SignatureProvided>mmfv/ddhhakla1csUrb/tRCXYu8=</SignatureProvided>
<StringToSignBytes>
47 45 54 0a 0a 0a 31 34 33 32 37 32 37 39 39 35 0a 2f 72 69 2d 73 65 72 76 69 63 65 2d 74 72 61 6b 2d 74 65 73 74 2f 74 65 73 74 53 75 6e 69 74 31 2e 78 6d 6c
</StringToSignBytes>
<RequestId>0E72b9858758353A0D906</RequestId>
<HostId>
SOME VALUE
</HostId>
</Error>
Another Question:
If I have an URI that has '+' in it, how do I access the page using the URI because trying the URI in the web browser turns it into space(" ") and that isn't correct?
Related
I have the following setup:
ATECC608A
mbedTLS (tested with 2.16.6 and 2.16.9)
coreMQTT
The certificate chain is the following: RootCA > SignerCA > DeviceCert. I've registered both RootCA and SignerCA as CAs in the AWS IoT Console
I setup the chain in mbedTLS with the following:
/* Extract the device certificate and convert to mbedtls cert */
if (0 != atca_mbedtls_cert_add(&device_cert_chain, &g_cert_def_2_device))
{
printf("Failed to parse device cert from device\n");
goto exit;
}
/* Extract the signer certificate, convert, then attach to the chain */
if (0 != atca_mbedtls_cert_add(&device_cert_chain, &g_cert_def_1_signer))
{
printf("Failed to parse signer cert from device\n");
goto exit;
}
When connecting to my ats-endpoint with that stack, the TLS handshake is successul: the device cert and signerCA are presented and AWS presents its cert chain as well. mbedTLS seems to be happy:
....[SNIP]
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:2898: <= parse server hello done
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3522: client state: 7
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2765: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5343: => write certificate
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: own certificate #1:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: cert. version : 3
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: serial number : 40:F7:D9:46:59:6E:2F:58:E6:87:04:4F:D5:6E:86:03
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issuer name : O=CompanyName, CN=signer.companyname.com FFFF
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: subject name : O=CompanyName, CN=pu0223528E47B3461DEE
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issued on : 2021-01-14 21:00:00
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: expires on : 3000-12-31 23:59:59
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: signed using : ECDSA with SHA256
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: EC key size : 256 bits
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: basic constraints : CA=false
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: key usage : Digital Signature, Key Agreement
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(X)' (256 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: c7 1f a4 ea e7 ae 51 16 fb c3 0b ce 33 f1 7a af
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: f1 27 3a af a7 5d 76 76 74 58 e8 56 36 94 56 76
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(Y)' (255 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: 5f a6 2e 21 53 a5 91 7d 95 f8 9e 0e f8 ce bd d9
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: c1 50 83 c2 7d 74 98 4b 66 b2 eb 9a b7 49 48 4c
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: own certificate #2:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: cert. version : 3
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: serial number : 4D:29:66:FF:B8:09:8D:39:0E:39:C8:3A:94:6E:EE:6A
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issuer name : O=CompanyName, CN=root.companyname.com FFFF
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: subject name : O=CompanyName, CN=signer.companyname.com FFFF
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: issued on : 2020-11-09 17:55:11
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: expires on : 2070-10-28 17:44:12
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: signed using : ECDSA with SHA256
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: EC key size : 256 bits
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: basic constraints : CA=true
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: key usage : Digital Signature, Key Cert Sign, CRL Sign
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(X)' (256 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: cc 63 87 d3 bd 58 08 1e c7 55 02 be a8 e1 d7 a2
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: f9 7f 62 0a 39 c6 40 45 cf 1d 83 4a 53 5e 6a e3
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: value of 'crt->eckey.Q(Y)' (255 bits) is:
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: 5b be ad 83 96 10 3c 0e 5b 0b 60 32 65 5d d3 3b
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5395: 77 90 b2 a7 a8 cb 90 b7 49 3f 24 cd c6 6b 1f 38
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3192: => write handshake message
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3351: => write record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3428: output record: msgtype = 22, version = [3:3], msglen = 982
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: dumping 'output record sent to network' (987 bytes)
....[SNIP]
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4399: <= read record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6606: <= parse finished
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3522: client state: 14
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2765: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3633: handshake: done
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_cli.c:3522: client state: 15
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2765: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6350: => handshake wrapup
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6323: => handshake wrapup: final free
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6343: <= handshake wrapup: final free
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:6405: <= handshake wrapup
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8108: <= handshake
ok
TLS Session Established and a Socket is ready for an Application
I then use the created mbedtls_ssl_context to connect coreMQTT. From log, coreMQTT is able to write on the socket but AWS closes the connection.
...[SNIP]...
TLS Session Established and a Socket is ready for an Application
Initializing MQTT...ok
Connecting to the MQTT broker with params:
- identifier='testclient'
- username='?SDK=Fedora&Version=33&Platform=PC&MQTTLib=core-mqtt#v1.1.0'
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8696: => write
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3351: => write record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1443: => encrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: dumping 'before encrypt: output payload' (85 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0000: 10 53 00 04 4d 51 54 54 04 82 00 3c 00 0a 74 65 .S..MQTT...<..te
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0010: 73 74 63 6c 69 65 6e 74 00 3b 3f 53 44 4b 3d 46 stclient.;?SDK=F
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0020: 65 64 6f 72 61 26 56 65 72 73 69 6f 6e 3d 33 33 edora&Version=33
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0030: 26 50 6c 61 74 66 6f 72 6d 3d 50 43 26 4d 51 54 &Platform=PC&MQT
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0040: 54 4c 69 62 3d 63 6f 72 65 2d 6d 71 74 74 40 76 TLib=core-mqtt#v
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1453: 0050: 31 2e 31 2e 30 1.1.0
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1572: dumping 'additional data for AEAD' (13 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1572: 0000: 00 00 00 00 00 00 00 01 17 03 03 00 55 ............U
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1602: dumping 'IV used (internal)' (12 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1602: 0000: 91 d1 a1 52 00 00 00 00 00 00 00 01 ...R........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1604: dumping 'IV used (transmitted)' (8 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1604: 0000: 00 00 00 00 00 00 00 01 ........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1614: before encrypt: msglen = 93, including 0 bytes of padding
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1641: dumping 'after encrypt: tag' (16 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1641: 0000: db 24 89 b1 5f 7f e6 ff 78 dd c3 8b 34 99 79 1f .$.._...x...4.y.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1779: <= encrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3428: output record: msgtype = 23, version = [3:3], msglen = 109
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: dumping 'output record sent to network' (114 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0000: 17 03 03 00 6d 00 00 00 00 00 00 00 01 ba 08 e9 ....m...........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0010: fb f4 64 84 4e 6d 31 6e 89 3f 7b 74 e1 9a 0a af ..d.Nm1n.?{t....
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0020: 82 33 4e 7b 13 23 de ba 55 19 41 24 6e 95 14 3c .3N{.#..U.A$n..<
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0030: 2a 6e 02 67 6d 76 4d f8 32 a0 45 ca 12 a2 1a 31 *n.gmvM.2.E....1
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0040: 97 26 45 13 88 07 2c 18 13 ab 92 4b 2b 98 41 49 .&E...,....K+.AI
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0050: 03 5a 4f a9 5d 95 33 2b 68 c9 16 ee 2a ad 59 0a .ZO.].3+h...*.Y.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0060: 7a 52 db 24 89 b1 5f 7f e6 ff 78 dd c3 8b 34 99 zR.$.._...x...4.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3433: 0070: 79 1f y.
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2753: => flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2771: message length: 114, out_left: 114
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2777: ssl->f_send() returned 114 (-0xffffff8e)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2805: <= flush output
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:3484: <= write record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8724: <= write
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8284: => read
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4325: => read record
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2534: => fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2694: in_left: 0, nb_want: 5
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2718: in_left: 0, nb_want: 5
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2720: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2740: <= fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4061: dumping 'input record header' (5 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4061: 0000: 15 03 03 00 1a .....
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4067: input record: msgtype = 21, version = [3:3], msglen = 26
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2534: => fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2694: in_left: 5, nb_want: 31
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2718: in_left: 5, nb_want: 31
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2720: ssl->f_recv(_timeout)() returned 26 (-0xffffffe6)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2740: <= fetch input
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4246: dumping 'input record from network' (31 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4246: 0000: 15 03 03 00 1a 00 00 00 00 00 00 00 01 33 90 3f .............3.?
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4246: 0010: df 0b 29 53 90 20 f1 90 14 82 84 99 e9 f6 db ..)S. .........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1792: => decrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1879: dumping 'additional data for AEAD' (13 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1879: 0000: 00 00 00 00 00 00 00 01 15 03 03 00 02 .............
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1908: dumping 'IV used' (12 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1908: 0000: 3a e9 5a f2 00 00 00 00 00 00 00 01 :.Z.........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1909: dumping 'TAG used' (16 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:1909: 0000: 3f df 0b 29 53 90 20 f1 90 14 82 84 99 e9 f6 db ?..)S. .........
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:2374: <= decrypt buf
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4273: dumping 'input payload after decrypt' (2 bytes)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4273: 0000: 01 00 ..
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5183: got an alert message, type: [1:0]
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:5199: is a close notify message
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:4383: mbedtls_ssl_handle_message_type() returned -30848 (-0x7880)
mbedtls-examples/cryptoauthlib/third_party/mbedtls/library/ssl_tls.c:8349: mbedtls_ssl_read_record() returned -30848 (-0x7880)
I expect the first connection to fail. But in this case, the certificate does not appear in the AWS IoT console and subsequent connection attempts fail as well.
I double checked the signerCA stored and its policy. They seem fine. To ensure that this confg is correct, I manually created a certificate on my machine and signed it with my SignerCA.I then used that certificate with mosquitto_pub. The process works and my certificate appears in the AWS IoT console with the correct policy attached. Here's a log of what I'm doing:
$ openssl genpkey -out fakeDeviceCert.key -algorithm EC -pkeyopt ec_paramgen_curve:P-256
$ openssl req -new -key fakeDeviceCert.key -out fakeDeviceCert.csr
$ openssl x509 -req -in fakeDeviceCert.csr -CA ../certs/signer-FFFF.crt \
-CAkey ../certs/signer-FFFF.key \
-CAcreateserial \
-out fakeDeviceCert.pem \
-days 357335 \
-sha256
$ cat fakeDeviceCert.pem ../certs/signer-FFFF.crt > deviceCertAndCACert.crt
$ mosquitto_pub --cafile AmazonRootCA1.pem \
--cert deviceCertAndCACertcrt --key fakeDeviceCert.key \
-h <redacted>-ats.iot.eu-central-1.amazonaws.com -p 8883 -q 1 -t ji/tp \
-i deviceCert --tls-version tlsv1.2 -m '{"let-me": "in"}' -d
Doing this, I know that the policy attached to my signerCA is correct and running well.
Another verification I've done is to check that my coreMQTT connection is correct. To connect without the JITP provisioning, I extracted the device certificate from the ATECC, manually uploaded its PEM and attached a policy to the device in the AWS console.
That MQTT connection was successful (and I see the 'MQTT.Connect event in the AWS logs).
Here's the relevant certs description. I've redacted the Issuer/Subject from the output so the signatures are incorrect:
The device cert stored in ATECC (the one that does not trigger the provisioning process):
$ openssl x509 -text -noout -in extracted_device_cert.pm
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
40:f7:d9:46:59:6e:2f:58:e6:87:04:4f:d5:6e:86:03
Signature Algorithm: ecdsa-with-SHA256
Issuer: O = CompanyName, CN = signer.companyname.com FFFF
Validity
Not Before: Jan 14 21:00:00 2021 GMT
Not After : Dec 31 23:59:59 3000 GMT
Subject: O = CompanyName, CN = pu0223528E47B3461DEE
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:c7:1f:a4:ea:e7:ae:51:16:fb:c3:0b:ce:33:f1:
7a:af:f1:27:3a:af:a7:5d:76:76:74:58:e8:56:36:
94:56:76:5f:a6:2e:21:53:a5:91:7d:95:f8:9e:0e:
f8:ce:bd:d9:c1:50:83:c2:7d:74:98:4b:66:b2:eb:
9a:b7:49:48:4c
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Agreement
X509v3 Subject Key Identifier:
4A:F0:38:0D:8E:57:76:71:A2:92:07:B7:60:1B:C7:0A:B4:7E:8B:D1
X509v3 Authority Key Identifier:
keyid:4C:E5:14:B2:9D:3E:8F:29:43:34:45:83:34:C2:F4:09:53:60:13:99
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:5c:86:11:4b:79:07:ce:34:32:61:6d:00:2a:7c:
43:75:16:e9:b6:ae:13:21:91:25:5f:1b:80:c3:b2:41:93:0d:
02:20:31:fc:4c:6d:5e:f0:54:46:da:ae:d7:aa:b7:f8:6a:c8:
21:ba:45:62:31:7b:55:f7:b3:38:af:7c:97:25:81:72
And the manually generated cert that correctly triggers the JITP:
$ openssl x509 -text -noout -in fakeDeviceCert.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
7a:50:78:20:5e:dc:de:56:74:55:fb:fa:6e:61:ed:13:ed:c9:0a:b7
Signature Algorithm: ecdsa-with-SHA256
Issuer: O = CompanyName, CN = signer.companyname.com FFFF
Validity
Not Before: Jan 15 08:22:44 2021 GMT
Not After : May 23 08:22:44 2999 GMT
Subject: O = CompanyName, CN = pu010203040506070811
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:62:1e:35:5a:97:ec:7f:f7:82:6e:67:7a:ac:a5:
1b:b0:a3:bc:42:08:cb:0e:fe:ad:07:46:0c:dd:8c:
ca:b3:60:8f:e3:0b:59:a4:b3:e5:6b:a5:22:8e:49:
d3:3a:1e:76:43:7b:7a:cd:dd:0d:dc:52:1f:8f:83:
ee:10:e0:fb:1a
ASN1 OID: prime256v1
NIST CURVE: P-256
Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:8f:3a:b4:e4:25:98:3c:79:23:65:e4:1b:68:
75:19:11:27:91:df:66:22:ea:c1:13:06:72:6f:e0:5d:3d:13:
49:02:21:00:e2:7e:2b:92:55:68:98:09:b9:a4:e9:7b:2a:7c:
48:2a:bb:23:c7:45:d2:96:ec:df:9b:62:a8:9d:7a:98:06:fe
Here's the signerCA description from AWS (with some redacted fields between <>)
$ aws iot describe-ca-certificate --certificate-id <my-ca-cert-id>
{
"certificateDescription": {
"certificateArn": "arn:aws:iot:eu-central-1:<accountID>:cacert/<ca-id>",
"certificateId": "<ca-id>",
"status": "ACTIVE",
"certificatePem": "-----BEGIN CERTIFICATE-----\n<pem-content>-----END CERTIFICATE-----\n",
"ownedBy": "<owner-account-id>",
"creationDate": "2021-01-11T10:40:58.736000+01:00",
"autoRegistrationStatus": "ENABLE",
"lastModifiedDate": "2021-01-14T23:38:52.132000+01:00",
"customerVersion": 2,
"generationId": "09eb8608-630c-4632-a1ef-0879f6f2dd6f",
"validity": {
"notBefore": "2020-11-09T18:55:11+01:00",
"notAfter": "2070-10-28T18:44:12+01:00"
}
},
"registrationConfig": {
"templateBody": "{\"Parameters\": {\"AWS::IoT::Certificate::CommonName\": {\"Type\": \"String\"}, \"AWS::IoT::Certificate::Id\": {\"Type\": \"String\"}}, \"Resources\": {\"thing\": {\"Type\": \"AWS::IoT::Thing\", \"Properties\": {\"ThingName\": {\"Ref\": \"AWS::IoT::Certificate::CommonName\"}, \"AttributePayload\": {\"version\": \"v1\"}}}, \"certificate\": {\"Type\": \"AWS::IoT::Certificate\", \"Properties\": {\"CertificateId\": {\"Ref\": \"AWS::IoT::Certificate::Id\"}, \"Status\": \"ACTIVE\"}}, \"policy\": {\"Type\": \"AWS::IoT::Policy\", \"Properties\": {\"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": [\\\"iot:Connect\\\", \\\"iot:Publish\\\", \\\"iot:Subscribe\\\", \\\"iot:Receive\\\", \\\"iot:GetThingShadow\\\", \\\"iot:DeleteThingShadow\\\", \\\"iot:UpdateThingShadow\\\"], \\\"Resource\\\": [\\\"*\\\"]}]}\"}}}}",
"roleArn": "arn:aws:iam::<account-id>:role/JITP-Role"
}
}
I'm a bit lost and have a few questions:
mbedTLS seems to present the two concatened certificates. Would the handshake be successful if one them was not correct or if mbedTLS was misconfigured?
Could the X509v3 extensions be responsible for the JITP failure? The device cert has them, while the manually-generated one has not.
Is there a way to log mutual authentication failures in Cloudwatch?
Is there anything that I missed?
(EDIT: If I don't include the signerCA in the cert chain when connecting, the TLS handshake is still successful. Of course, in that case I expect the JITP process to fail because AWS cannot find the associated CA).
EDIT2:
I've tried to connect with mosquitto and a certificate that is much closer to the one used by the ATECC (same algos and same X509v3 extensions). The outcome is the same: the manually generated one with mosquitto can trigger the JITP while the one from ATECC cannot.
Got it. I was retrieving the public key of my root certificate in the wrong slot in the ATECC (ouch). This was resulting in a slightly different signerCA to be generated by the atcacert_def_t and the template at runtime.
I missed it because all my tooling in Python was fetching the right slot while the C version was not kept perfectly in sync.
Im trying to create presigned urls to give download access to private files that live on an S3 bucket. I have 2 buckets, one on us-east-1 and the other on eu-west-3.
I've tried creating the presigned url with both AWS CLI and Python SDK (Boto 3) but didn't manage to get lucky when doing it on the EU bucket. On the us-east-1, i can do it with V2 and V4 signing.
The server always returns this response:
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>MYACCESSKEY</AWSAccessKeyId><StringToSign>AWS4-HMAC-SHA256
20190829T174117Z
20190829/eu-west-3/s3/aws4_request
e57ecda0a9ef1693b962d285c1748bd28284d2e2d069bceb44fad975e480b964</StringToSign><SignatureProvided>674e84fda296c6d0e14ff8dd6a02f9af92d08ed2f6556547c63cbd057603148f</SignatureProvided><StringToSignBytes></StringToSignBytes>
<CanonicalRequest>GET
/public/video.mp4
X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=MYACCESSKEY%2F20190829%2Feu-west-3%2Fs3%2Faws4_request&X-Amz-Date=20190829T174117Z&X-Amz-Expires=600&X-Amz-SignedHeaders=host
host:mybucket.s3.eu-west-3.amazonaws.com
host
UNSIGNED-PAYLOAD</CanonicalRequest>
<CanonicalRequestBytes>47 45 54 0a 2f 70 75 62 6c 69 63 2f 76 69 64 65 6f 2e 6d 70 34 0a 58 2d 41 6d 7a 2d 41 6c 67 6f 72 69 74 68 6d 3d 41 57 53 34 2d 48 4d 41 43 2d 53 48 41 32 35 36 26 58 2d 41 6d 7a 2d 43 72 65 64 65 6e 74 69 61 6c 3d 41 4b 49 41 5a 54 48 34 47 4b 4b 57 58 42 55 59 48 46 55 59 25 32 46 32 30 31 39 30 38 32 39 25 32 46 65 75 2d 77 65 73 74 2d 33 25 32 46 73 33 25 32 46 61 77 73 34 5f 72 65 71 75 65 73 74 26 58 2d 41 6d 7a 2d 44 61 74 65 3d 32 30 31 39 30 38 32 39 54 31 37 34 31 31 37 5a 26 58 2d 41 6d 7a 2d 45 78 70 69 72 65 73 3d 36 30 30 26 58 2d 41 6d 7a 2d 53 69 67 6e 65 64 48 65 61 64 65 72 73 3d 68 6f 73 74 0a 68 6f 73 74 3a 65 75 73 74 6f 72 65 2d 6d 6f 68 6f 2e 73 33 2e 65 75 2d 77 65 73 74 2d 33 2e 61 6d 61 7a 6f 6e 61 77 73 2e 63 6f 6d 0a 0a 68 6f 73 74 0a 55 4e 53 49 47 4e 45 44 2d 50 41 59 4c 4f 41 44</CanonicalRequestBytes>
<RequestId>496495C76B32097B</RequestId>
<HostId>Eue5AWLgtRWvivCE9ralzfc1ilUrLsnT+bWakSbeR5JYoSk1vbhYpwFxbeDbozJ7f1X1KLA5+Zc=</HostId></Error>
I obscured the bucket name and access key.
Here it is my python code: I'm using boto3-1.9.218 botocore-1.12.218 and Python 2.7.13.
import logging
import boto3
from botocore.exceptions import ClientError
import requests
from botocore.client import Config
'''
region = 'us-east-1'
tbucket = '<usbucket>'
'''
region = 'eu-west-3'
tbucket = '<eubucket>'
filekey = 'public/video.mp4'
s3 = boto3.client(
's3',
# Hard coded strings as credentials, not recommended.
aws_access_key_id='<access_key_id>',
aws_secret_access_key='<secret>',
config=Config(signature_version='s3v4'),
region_name=region
)
# This works
response = s3.list_buckets()
print('Existing buckets:')
for bucket in response['Buckets']:
print(bucket["Name"])
# this works
s3.download_file(tbucket, filekey, 'some video.mp4')
# this works
url = ""
try:
url = s3.generate_presigned_url('get_object', Params={ 'Bucket': tbucket, 'Key': filekey }, ExpiresIn=600)
except ClientError as e:
logging.error(e)
# Using the url does not work. Error 403
print(url)
if url is not None:
response = requests.get(url)
print(response)
I am struggling for a few weeks with zlib inflate alghorithm.
I would like to decompress packets from popular game called Tibia. They have compressed it with zlib inflate alghorithms. But it seems something is changed. Can you check it, maybe you will spot something I am missing?
Packet compressed: - cannot be inflated directly (its raw huffman fixed coding - probably)
DA 22 A6 CB 10 99 5F AA 50 9C 9A AA 90 A8 90 05 B4 2F B5 44 41 C3 B1 28 D7 CA 50 53 8F CB B3 44 A1 3C 35 33 3D A3 58 C1 C8 44 CF C0 40 21 BF 4A 0F
Packet decompressed using Reverse Engineering:
B4 16 2D 00 59 6F 75 20 73 65 65 20 61 20 6A 61 63 6B 65 74 20 28 41 72 6D 3A 31 29 2E 0A 49 74 20 77 65 69 67 68 73 20 32 34 2E 30 30 20 6F 7A 2E
Decompressed packet compressed with zlib deflate using CyberChef deflate / php deflate functions:
db 22 a6 cb 10 99 5f aa 50 9c 9a aa 90 a8 90 95 98 9c 9d 5a a2 a0 e1 58 94 6b 65 a8 a9 c7 e5 59 a2 50 9e 9a 99 9e 51 ac 60 64 a2 67 60 a0 90 5f a5 07 00
Data matches in a few places, but generally, its different. Do you know what could be the case?
I attach a picture from RE an inflating function: Screenshot from IdaPro
Here are packets in correct order:
http://wklej.org/hash/6aee9e223f0/txt/ - inflated correctly
http://wklej.org/hash/bd371e7f510/txt/ - inflated correctly
http://wklej.org/hash/8f15935dc15/txt/ - inflated correctly
And here is the packet that cannot be inflated...
CA059BC6043619009FC9FFFFE831
Your packet that cannot be inflated is likely part of a longer stream of compressed data, with other packets preceding it and following it. You need to decompress all of them as a single stream for the decompression to succeed.
Your first example is a portion of a deflate stream that references data that preceded it. So it is part of a larger deflate stream. You need all of the compressed data that preceded that piece in order to decompress that piece. Your last example (CA05...) also references preceding data, so it too is part of a larger stream with compressed data that preceded it.
The simple workflow for deploying/invoking a chaincode (to my knowledge) is :
Deploy a chaincode(smart contract) on the blockchain
This brings up a docker container on all peers that has the chaincode running in it
Invoke some function
This type of function changes the values of variables in chaincode state
For asset_management.go, the chaincode can be tested by running go test in the asset_management chaincode directory . But this does not really bring up a docker container(or does it ?) that runs the asset_management chaincode.
Whats the right way to deploy/invoke this chaincode and how is it different from deploying/invoking chaincodes using the REST interface(like we do for chaincode_example02)
The chaincode workflow you mentioned is correct, just one detail regarding variables in chaincode state: the variables are stored in a global key-value collection named World State, which is accessed through the invocation of a chaincode and it is access protected.
Now, what you are doing with go test is running the code in asset_management_test.go. If you look at this code, you will see that it basically starts a VP and a CA and then tries sending transactions to tests that the chaincode works. For example:
// Now create the Transactions message and send to Peer.
transaction, err := txHandler.NewChaincodeExecute(chaincodeInvocationSpec, tid)
You could also code a test file for the chaincode_example02 and test it.
Or you can also deploy the asset_management chaincode the same way you use to deploy chaincode_example02. Which can be using a chaincode development environment or a development network.
Important: asset_management chaincode is used to test the invocation access control, so it is fairly complex. Invoking its methods means using digital signatures to check the identity of the chaincode invoker. You can check the asset_management_test file to see how it is done.
The list of steps for anybody who would like to run “asset_management_with_roles” manually:
Checkout Fabric, run vagrant from “devenv” folder
ssh to the started container.
Reset Fabric’s configuration:
rm /var/hyperledger/production
Enable attribute certificate authority in membersrvc.yaml
aca.enabled: true
Enable security in core.yaml
security.enable: true
Switch log level for “node” to “debug” in core.yaml (optional. not necessary if you know the certificates)
logging.node: debug
Run membersrvc in background:
nohup membersrvc &> /tmp/membersrvc.log &
Run peer service
peer node start
Verify if users “assigner, bob, alice” are in membersrvc.yaml, according to the comment in this example we will work with:
// This example implements asset transfer using attributes support and specifically Attribute Based Access Control (ABAC).
// There are three users in this example:
// - alice
// - bob
// - assigner
//
// This users are defined in the section “eca" of asset.yaml file.
// In the section “aca" of asset.yaml file two attributes are defined to this users:
// The first attribute is called ‘role' with this values:
// - alice has role = client
// - bob has role = client
// - assigner has role = assigner
//
// The second attribute is called ‘account' with this values:
// - alice has account = 12345-56789
// - bob has account = 23456-67890
Open another ssh terminal with vagrant and login to the network:
peer network login assigner -p Tc43PeqBl11
peer network login bob -p NOE63pEQbL25
peer network login alice -p CMS10pEQlB16
8. Deploy chaincode to the network using “assigner” security context:
curl -XPOST -d ‘{“jsonrpc": "2.0", "method": "deploy", "params": {"type": 1,"chaincodeID": {"path": "github.com/hyperledger/fabric/examples/chaincode/go/asset_management_with_roles","language": "GOLANG"}, "ctorMsg": { "args": ["init"] }, "metadata":[97, 115, 115, 105, 103, 110, 101, 114] ,"secureContext": "assigner"} ,"id": 0}' http://localhost:7050/chaincode
metadata contains utf-8 encoded string “assigner”. This string will be saved in a ledger and only user with such role will be able to execute “assign” function in smart contract.
In order to keep example readable lets save chaincode id in local variable:
export HASH=7adc030881c07c39d2edac0b1560bf7cf2b7f0a4bce74fe7e6144e3f36e1bf2d176093d4c23ba58712a9589d9600e6d9ef596a1521a4c5227c222d8af2bf16c8
Starting from this moment user “assigner” can create new assets for bob and alice, we just have to find their certificates.
let’s run query command for any random asset name under “bob” securityContext:
curl -XPOST -d '{"jsonrpc": "2.0", "method": "query", "params": {"type": 1, "chaincodeID": {"name": "'"$HASH"'"}, "ctorMsg": {"args": ["query", "myasset"]}, "secureContext": "bob", "attributes": ["role", "account"]}, "id": 1}' http://localhost:7050/chaincode
(IMPORTANT: without “attributes”: [“role”, “account”] no attributes will be loaded into transactions certificate)
As far as “peer” is started in debug mode, bob’s certificate will be printed in peer log output. Try to find row “[client.bob] Adding new Cert” and copy certificate value:
30 82 02 90 30 82 02 37 a0 03 02 01 02 02 10 2f 9e 4e da c9 e9 4e 97 b1 58 24 78 4e 15 05 f4 30 0a 06 08 2a 86 48 ce 3d 04 03 03 30 31 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 14 30 12 06 03 55 04 0a 13 0b 48 79 70 65 72 6c 65 64 67 65 72 31 0c 30 0a 06 03 55 04 03 13 03 74 63 61 30 1e 17 0d 31 36 30 39 31 39 32 31 32 34 31 39 5a 17 0d 31 36 31 32 31 38 32 31 32 34 31 39 5a 30 45 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 14 30 12 06 03 55 04 0a 13 0b 48 79 70 65 72 6c 65 64 67 65 72 31 20 30 1e 06 03 55 04 03 13 17 54 72 61 6e 73 61 63 74 69 6f 6e 20 43 65 72 74 69 66 69 63 61 74 65 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 86 48 ce 3d 03 01 07 03 42 00 04 78 8f f2 11 55 a3 5a 8d f1 b5 4f 38 e4 94 e4 67 b0 47 7f e0 07 04 b8 fb 12 ee 86 17 8a 05 55 e3 98 f6 c1 af 59 ee 2d 54 a9 c5 36 22 cd fa a8 1b ce ba e0 26 fd 73 40 af 20 5d 15 65 89 9c 62 64 a3 82 01 1b 30 82 01 17 30 0e 06 03 55 1d 0f 01 01 ff 04 04 03 02 07 80 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 0d 06 03 55 1d 0e 04 06 04 04 01 02 03 04 30 0f 06 03 55 1d 23 04 08 30 06 80 04 01 02 03 04 30 10 06 06 2a 03 04 05 06 0a 04 06 63 6c 69 65 6e 74 30 15 06 06 2a 03 04 05 06 0b 04 0b 32 33 34 35 36 2d 36 37 38 39 30 30 4d 06 06 2a 03 04 05 06 07 01 01 ff 04 40 fc c2 07 dd ee ac 8c 76 84 12 07 d2 e0 a6 da b3 06 c9 5b 5b 41 57 a3 f3 a2 f7 59 e2 ed 02 02 7e 56 46 f5 bc 24 00 0a 2e 18 b4 a6 b7 a6 c3 8d ca 15 13 a7 98 42 98 8f 9b 85 a2 d1 6a 77 0d da e8 30 3a 06 06 2a 03 04 05 06 08 04 30 ff d2 ab 7f c8 2d 98 c4 3f c9 f7 05 12 07 01 3a 36 69 f8 ee d1 c4 27 16 48 3e ee ed db b9 b6 3c d6 e5 1a 3e 0b 7d f0 19 1c 81 03 12 f6 7b d5 3e 30 23 06 06 2a 03 04 05 06 09 04 19 30 30 48 45 41 44 72 6f 6c 65 2d 3e 31 23 61 63 63 6f 75 6e 74 2d 3e 32 23 30 0a 06 08 2a 86 48 ce 3d 04 03 03 03 47 00 30 44 02 20 49 52 26 bd b8 f4 a0 98 c6 ff fc 56 3e b5 b0 12 ee ec b7 46 90 55 b1 17 99 29 fe df 80 2e 95 b9 02 20 3b 7f dd 32 88 56 ae a1 14 60 54 60 95 61 fb d1 bc 0c f7 e0 61 f2 e9 0b 46 35 6a 36 61 c9 b8 f0
Certificate should be based64 encoded. As an option we can use http://tomeko.net/online_tools/hex_to_base64.php?lang=en
Insert certificate into “Hex string” field, click “convert” button, and result will be in “Output (base64)”:
MIICkjCCAjigAwIBAgIRAO9nis6q+khvv6TMvhKbmacwCgYIKoZIzj0EAwMwMTELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0h5cGVybGVkZ2VyMQwwCgYDVQQDEwN0Y2EwHhcNMTYwOTE5MjAyMDE5WhcNMTYxMjE4MjAyMDE5WjBFMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLSHlwZXJsZWRnZXIxIDAeBgNVBAMTF1RyYW5zYWN0aW9uIENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqop3N0IpJaLVaRuYioSuHPvyWX3OY9vo4I1YYw1YophcFGFt3fN0X6bDlufUZ5/u81JMmZHozduREnNzM1n+gaOCARswggEXMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwEAYGKgMEBQYKBAZjbGllbnQwFQYGKgMEBQYLBAsyMzQ1Ni02Nzg5MDBNBgYqAwQFBgcBAf8EQNbPDmdWcOogMkZrlxbRJw/06jg4Ai88KW2+BsuxUnIH5FSa3OY7ZsXJLpceIN4SeEWKDKDsIPCo2wm6cUMYApIwOgYGKgMEBQYIBDDikSBKFYtTmYZRhtVDPhnIoSvefWHQ5Vx5oahIRbG8d/w4J1YTrtVoEwa2jikAqJowIwYGKgMEBQYJBBkwMEhFQURyb2xlLT4xI2FjY291bnQtPjIjMAoGCCqGSM49BAMDA0gAMEUCIQCrUQw2moOA5RFEx/780so4uEOV5esX3fy/It0t2la7gQIgGGVoDoM2kSxWH7TtV4T8W4pY6tN/LXu8XpKWb8+eF0k=
"assign" method expects 2 parameters the Name for asset and owner certificate. New asset can be created using:
curl -XPOST -d '{"jsonrpc": "2.0", "method": "invoke", "params": {"type": 1, "chaincodeID": {"name": "'"$HASH"'"}, "ctorMsg": {"args": ["assign", "myasset", "MIICkjCCAjigAwIBAgIRAO9nis6q+khvv6TMvhKbmacwCgYIKoZIzj0EAwMwMTELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0h5cGVybGVkZ2VyMQwwCgYDVQQDEwN0Y2EwHhcNMTYwOTE5MjAyMDE5WhcNMTYxMjE4MjAyMDE5WjBFMQswCQYDVQQGEwJVUzEUMBIGA1UEChMLSHlwZXJsZWRnZXIxIDAeBgNVBAMTF1RyYW5zYWN0aW9uIENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqop3N0IpJaLVaRuYioSuHPvyWX3OY9vo4I1YYw1YophcFGFt3fN0X6bDlufUZ5/u81JMmZHozduREnNzM1n+gaOCARswggEXMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAAMA0GA1UdDgQGBAQBAgMEMA8GA1UdIwQIMAaABAECAwQwEAYGKgMEBQYKBAZjbGllbnQwFQYGKgMEBQYLBAsyMzQ1Ni02Nzg5MDBNBgYqAwQFBgcBAf8EQNbPDmdWcOogMkZrlxbRJw/06jg4Ai88KW2+BsuxUnIH5FSa3OY7ZsXJLpceIN4SeEWKDKDsIPCo2wm6cUMYApIwOgYGKgMEBQYIBDDikSBKFYtTmYZRhtVDPhnIoSvefWHQ5Vx5oahIRbG8d/w4J1YTrtVoEwa2jikAqJowIwYGKgMEBQYJBBkwMEhFQURyb2xlLT4xI2FjY291bnQtPjIjMAoGCCqGSM49BAMDA0gAMEUCIQCrUQw2moOA5RFEx/780so4uEOV5esX3fy/It0t2la7gQIgGGVoDoM2kSxWH7TtV4T8W4pY6tN/LXu8XpKWb8+eF0k="]}, "metadata":[97, 115, 115, 105, 103, 110, 101, 114], "secureContext": "assigner", "attributes": ["role", "account"]}, "id": 1}' http://localhost:7050/chaincode
Try to run the query from step 9 for bob again:
curl -XPOST -d ‘{"jsonrpc": "2.0", "method": "query", "params": {"type": 1, "chaincodeID": {"name": "'"$HASH"'"}, "ctorMsg": {"args": ["query", "myasset"]}, "secureContext": "bob", "attributes": ["role", "account"]}, "id": 1}' http://localhost:7050/chaincode
and you will see that “myasset” is already created, and belongs to account “23456-67890”
Using the same approach we can find certificate for alice and change the owner for “myasset”.
I've implemented a very basic CustomResource where I'm receiving the notification through SNS to an HTTPS subscriber without any problems. If I take the ResponseURL sent with the CustomResource notification and try to respond with a SUCCESS response, I continually get a 403-FORBIDDEN response from AWS using the pre-signed URL with a SignatureDoesNotMatch error code.
Through all my research and reviewing the aws-cfn-resource-bridge, there are two things that stand out.
The response is a PUT, good... easy enough.
The Content-Type HTTP header is set to a blank/empty string, alright... no problem there either although it doesn't make much sense.
Here is my request
PUT https://cloudformation-custom-resource-response-useast1.s3.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-1%3A741849072915%3Astack/scott-test/7181a360-50cc-11e5-8aae-5001b491380a%7CCloudFlareDNSRegistration%7C047ca252-bf0e-4fa7-a7ac-be97fc897095?AWSAccessKeyId=REMOVED&Expires=1441240852&Signature=yzmop7aF5TxOFjAG%2F7TvTpoZDS0%3D
Content-Type:
Content-Length: 305
{"Status":"SUCCESS","PhysicalResourceId":"scott-test- CloudFlareDNSRegistration-1KQIGCB3BP1AW","StackId":"arn:aws:cloudformation:us-east-1:741849072915:stack/scott-test/7181a360-50cc-11e5-8aae-5001b491380a","RequestId":"047ca252-bf0e-4fa7-a7ac-be97fc897095","LogicalResourceId":"CloudFlareDNSRegistration"}
The response I get:
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>REMOVED</AWSAccessKeyId><StringToSign>PUT
1441240852
/cloudformation-custom-resource-response-useast1/arn%253Aaws%253Acloudformation%253Aus-east-1%253A741849072915%253Astack/scott-test/7181a360-50cc-11e5-8aae-5001b491380a%257CCloudFlareDNSRegistration%257C047ca252-bf0e-4fa7-a7ac-be97fc897095</StringToSign> <SignatureProvided>yzmop7aF5TxOFjAG%2F7TvTpoZDS0%3D</SignatureProvided> <StringToSignBytes>50 55 54 0a 0a 0a 31 34 34 31 32 34 30 38 35 32 0a 2f 63 6c 6f 75 64 66 6f 72 6d 61 74 69 6f 6e 2d 63 75 73 74 6f 6d 2d 72 65 73 6f 75 72 63 65 2d 72 65 73 70 6f 6e 73 65 2d 75 73 65 61 73 74 31 2f 61 72 6e 25 32 35 33 41 61 77 73 25 32 35 33 41 63 6c 6f 75 64 66 6f 72 6d 61 74 69 6f 6e 25 32 35 33 41 75 73 2d 65 61 73 74 2d 31 25 32 35 33 41 37 34 31 38 34 39 30 37 32 39 31 35 25 32 35 33 41 73 74 61 63 6b 2f 73 63 6f 74 74 2d 74 65 73 74 2f 37 31 38 31 61 33 36 30 2d 35 30 63 63 2d 31 31 65 35 2d 38 61 61 65 2d 35 30 30 31 62 34 39 31 33 38 30 61 25 32 35 37 43 43 6c 6f 75 64 46 6c 61 72 65 44 4e 53 52 65 67 69 73 74 72 61 74 69 6f 6e 25 32 35 37 43 30 34 37 63 61 32 35 32 2d 62 66 30 65 2d 34 66 61 37 2d 61 37 61 63 2d 62 65 39 37 66 63 38 39 37 30 39 35</StringToSignBytes><RequestId>EBFDA09E56D8313F</RequestId><HostId>MP66HkmQeXXH05wE2AQR4pWc99JFyCXJMfMSQk4xxbxSRj5qQJB7vAm7/dJH+rH4</HostId></Error>
I've found various questions where it was suggested the path needed to be decoded (i.e. altering the %3A to :) before making the request, I tried that with no luck. I'm using the URL provided as is in the ResponseURL field, doesn't seem like I should be altering it.
Any thoughts?
Through trial and error I was able to get the signatures to match. The details are to long to post unfortunately, but my original attempt was leveraging Spring's RestTemplate, where I attempted to get the headers correctly set for AWS. I switched to a straight Http Components HttpClient approach where I had more control of the actual HTTP request headers and body.