SSL OCSP Exchange
This post rounds out my longer-than-anticipated five-part series walking through an entire modern TLS handshake. The only part of the handshake I didn't examine in my previous posts is the OCSP response, which I'll cover in this post.
OCSP stands for "Online Certificate Status Protocol". It represents the IETF's second attempt to address the problem of how to manage compromised SSL server certificates. An SSL certificate is only as useful as the secrecy of its private key; however, once it's been signed by a certificate authority, a certificate can be used to verify the identity of a web site until the end of its validity period, typically one or two years. So what is a web site administrator to do if the private key is discovered to be compromised? The first suggestion was that the certificate authority maintain a list of all compromised certificates, identified by serial number, called a Certificate Revocation List (CRL). Before accepting a certificate as a genuine identifier of a web site, a web client (such as a browser) was supposed to download the CRL, verify its signature, and double-check to ensure that the serial number included in the certificate was not one of the revoked certificates.
Before long, though, this got to be unwieldy for even moderately busy certificate authorities. As the CRL's grew longer and longer, the overhead of validating certificates against them started to drag down the overall productivity of the web. Potentially worse, there was no guarantee on the timeliness of a CRL: since the CRL listed every revoked certificate that the CA had ever issued, there was a lag between the reporting of the compromise and the update of the CRL itself. In response, the IETF drafted RFC 2560, which specified the Online Certificate Status Protocol that was meant to allow the browser to check the status of one single certificate (e.g. the one that had just been presented to it) with the CA before accepting it.
The idea behind OCSP, as originally specified by RFC 2560, was that, during SSL handshake, the client (browser) would:
- parse the certificate to determine the location of the OCSP responder
- initiate a new TCP connection to the OCSP responder
- Download the OCSP status response specific to the certificate that the site had just presented
- Validate the response and continue the handshake only if the response indicated that the certificate was valid.
Although this solved the volume problem and the latency problem associated with CRLs, it left remaining the problems of the delay introduced by connecting to a different server as well as the thornier problem of what, exactly, the browser should do if it didn't get any response at all. Most browsers, if they supported OCSP at all, went ahead and considered no response as a valid response — effectively defeating the purpose of the OCSP check in the first place.
With the publication of RFC 6066, the IETF launched its third attempt at solving the certificate revocation problem: OCSP stapling. It occurred to the designers that, as long as the OCSP response was signed, and the signature could be verified, it didn't matter necessarily where the OCSP response itself came from. Accordingly, it was perfectly legitimate for the server to cache the most recent OCSP response, signed by the CA, and return that immediately after the certificate. It's up to the client to indicate that it wants and supports OCSP stapling - you can see that when I first initiated the handshake that I've been walking through, the client kicked off an OCSP request with a pair of SSL Client Hello extensions: the OCSP request and the signed certificate timestamp. There's not much to the request in the extension - if the extension is present it means, "I want OCSP if you can give it to me." It's up the the server to satisfy the request; if it can't, and there's no OCSP response returned, it's up to the client to either abort the connection, warn the user, or fall back to real-time OCSP.
In this case, though, the server (wikipedia) was able to satisfy my browsers request for a "stapled"
OCSP response inline with the certificate.
Figure 1, below, is a tcpdump capture of a full OCSP status response. As you
can see from the figure, the response spanned two TCP segments, and started in the middle of
another one (it was followed by a server key exchange message as required by the TLS specification,
but I've omitted that here since I'm focusing on the OCSP response.)
16 0303 064f 1600
0x0140: 064b 0100 0647 3082 0643 0a01 00a0 8206
0x0150: 3c30 8206 3806 092b 0601 0505 0730 0101
0x0160: 0482 0629 3082 0625 3081 bfa2 1604 149c
0x0170: 4d00 9900 0e8b b001 8175 a1ba f0d0 25d7
0x0180: a01c 4718 0f32 3031 3730 3831 3431 3334
0x0190: 3130 325a 306f 306d 3045 3009 0605 2b0e
0x01a0: 0302 1a05 0004 140c 9e4d 9c3d edef 84d8
0x01b0: 91e9 72c7 cf84 06bc 197b 0704 1496 de61
0x01c0: f1bd 1c16 2953 1cc0 cc7d 3b83 0040 e61a
0x01d0: 7c02 0c10 e6fc 62b7 418a d500 5e45 b680
0x01e0: 0018 0f32 3031 3730 3831 3431 3334 3130
0x01f0: 325a a011 180f 3230 3137 3038 3138 3133
0x0200: 3431 3032 5aa1 2330 2130 1f06 092b 0601
0x0210: 0505 0730 0102 0412 0410 f868 3d2c 1fea
0x0220: 62ff cca1 889e 51ef c905 300d 0609 2a86
0x0230: 4886 f70d 0101 0b05 0003 8201 0100 35f2
0x0240: bf4c e7a1 490d bf76 0345 b630 586b e3c0
0x0250: db7d c33c c621 e300 4a68 be82 3b9f a28e
0x0260: fa4a f342 6d33 47a0 a55a 249d cb57 5311
0x0270: 3778 f969 f213 444d 745e 6987 27ac 145d
0x0280: 9307 3aa1 c93a ec22 3777 5b17 d66a f1f6
0x0290: 6525 2e86 b6b6 0b6a cf94 f665 1db1 a855
0x02a0: b136 8081 b07a 1def b5ba a4cf e482 465a
0x02b0: 2a86 8202 eaaf b609 500c ee0f c237 e3e3
0x02c0: 3766 6528 be27 42e4 1763 b1a8 9216 04eb
0x02d0: f3cd 5551 1e38 8870 d9ed 8bbb 1ab3 dfc0
0x02e0: 8995 1b83 086c aa4e 8316 aed1 4071 2343
0x02f0: a22a e981 ba87 0da2 36d9 7082 c688 349b
0x0300: 554d 62a9 01da f079 f2e3 1e33 2484 4b17
0x0310: 5b5c 8178 c3fb 284e 79a7 26fd 4efd 2742
0x0320: b345 67c7 175a 9585 0e67 ffbe 26d2 5fd3
0x0330: 48ea bb44 6e4a b1d6 ca9f 7617 cb36 a082
0x0340: 044b 3082 0447 3082 0443 3082 032b a003
0x0350: 0201 0202 0c7a 915e 55dd 3d5b 2719 d6eb
0x0360: 2730 0d06 092a 8648 86f7 0d01 010b 0500
0x0370: 3066 310b 3009 0603 5504 0613 0242 4531
0x0380: 1930 1706 0355 040a 1310 476c 6f62 616c
0x0390: 5369 676e 206e 762d 7361 313c 303a 0603
0x03a0: 5504 0313 3347 6c6f 6261 6c53 6967 6e20
0x03b0: 4f72 6761 6e69 7a61 7469 6f6e 2056 616c
0x03c0: 6964 6174 696f 6e20 4341 202d 2053 4841
0x03d0: 3235 3620 2d20 4732 301e 170d 3137 3037
0x03e0: 3137 3039 3132 3534 5a17 0d31 3731 3031
0x03f0: 3730 3931 3235 345a 3081 8e31 0b30 0906
0x0400: 0355 0406 1302 4245 3119 3017 0603 5504
0x0410: 0a13 1047 6c6f 6261 6c53 6967 6e20 6e76
0x0420: 2d73 6131 1530 1306 0355 0405 130c 3230
0x0430: 3137 3037 3137 3030 3138 314d 304b 0603
0x0440: 5504 0313 4447 6c6f 6261 6c53 6967 6e20
0x0450: 4f72 6761 6e69 7a61 7469 6f6e 2056 616c
0x0460: 6964 6174 696f 6e20 4341 202d 2053 4841
0x0470: 3235 3620 2d20 4732 202d 204f 4353 5020
0x0480: 5265 7370 6f6e 6465 7230 8201 2230 0d06
0x0490: 092a 8648 86f7 0d01 0101 0500 0382 010f
0x04a0: 0030 8201 0a02 8201 0100 d243 97cf 306a
0x04b0: e3d9 52ce dba7 ebde 058b d730 1322 c865
0x04c0: a826 de36 278a 6496 fafa 5fa9 0a05 17f5
0x04d0: 38f0 91aa 59f5 ceb7 c12f 9dc9 7a7f a32d
0x04e0: 6869 af6b 18e0 b9fd 9aae ed44 b714 b9a5
0x04f0: d5fc ff83 ed75 1706 3e68 1bc1 b9fc 5432
0x0500: 2e92 7e0f f12a 3bbf d69f 761d 5ea2 2164
0x0510: eca8 eaf7 0cca fa38 8370 da65 a6a2 6d65
0x0520: d515 943e acee 5696 e1a5 6c13 07bb 5019
0x0530: 3686 5681 c547 e5d3 3b58 9b07 7fdc b9fe
0x0540: 0631 3255 1629 44d1 4528 6c64 51ea 0d87
0x0550: 3637 cd10 40aa 9d1d 1cfd c76c f094 1941
0x0560: 9e3e 6ce9 f3bd bcdd f46d 05d4 653b d8b1
0x0570: 9380 b76e f67e 9090 5762 813f a28b 6745
0x0580: d58c b890 98b9 b361 e04b 4df9 46ce 1382
0x0590: 7d81 716f 3b53 e504 1c60 2fd6 1273 9298
0x05a0: eb96 361c f78d a147 eb61 0203 0100 01a3
0x05b0: 81c7 3081 c430 1d06 0355 1d0e 0416 0414
0x05c0: 9c4d 0099 000e 8bb0 0181 75a1 baf0 d025
0x05d0: d7a0 1c47 301f 0603 551d 2304 1830 1680
0x05e0: 1496 de61 f1bd 1c16 2953
14:23:15.027091 IP text-lb.ulsfo.wikimedia.org.https > 198.168.0.1.54502: Flags [P.], seq 4345:4892,
ack 206, win 59, options [nop,nop,TS val 567015122 ecr 523958231], length 547
... (IP and TCP headers omitted)
0x0040: 1cc0 cc7d 3b83 0040 e61a 7c30 0f06
0x0050: 092b 0601 0505 0730 0105 0402 0500 304c
0x0060: 0603 551d 2004 4530 4330 4106 092b 0601
0x0070: 0401 a032 015f 3034 3032 0608 2b06 0105
0x0080: 0507 0201 1626 6874 7470 733a 2f2f 7777
0x0090: 772e 676c 6f62 616c 7369 676e 2e63 6f6d
0x00a0: 2f72 6570 6f73 6974 6f72 792f 300e 0603
0x00b0: 551d 0f01 01ff 0404 0302 0780 3013 0603
0x00c0: 551d 2504 0c30 0a06 082b 0601 0505 0703
0x00d0: 0930 0d06 092a 8648 86f7 0d01 010b 0500
0x00e0: 0382 0101 001b 0d8b 0b75 fb4b 414a b8ca
0x00f0: db3d 7377 ac26 b821 9a31 9b94 76d2 6137
0x0100: 383f c3d9 1d3d 685d 306c f1cd 912d 4333
0x0110: f73b 4086 c32f 07e8 6125 7666 c40e 5950
0x0120: 8d4a 9c02 fd21 dbad 8051 0e87 4cfd 9e04
0x0130: e77c ccf3 34a1 4a27 34c7 599f 78fe 7a43
0x0140: a228 3d92 9550 a0fc 1a95 7527 a9bb afd1
0x0150: ddf2 b756 234c 7769 841f ee20 e87e a842
0x0160: 2be8 ed7a 0109 5e40 b23c a448 a899 2d36
0x0170: 1bdf 75a7 893d ee72 8a10 9923 4b7f 9de0
0x0180: ce30 88dd e580 fcc4 860f d95d 4f34 f3b7
0x0190: eb33 5ad5 1d80 d464 50a3 fceb f0fe 8426
0x01a0: 270d ee86 33ff cb2f b554 5adf 6d80 f179
0x01b0: d760 7cd5 db84 546c 7543 3141 4da2 68ef
0x01c0: 63eb 6a0b b765 f860 8614 4271 bb53 966c
0x01d0: 62f3 b17b 49ec eea4 8f76 4c12 b857 d28d
0x01e0: 6bb1 ed76 ed
Figure 1: captured OCSP status response
The entire OCSP response, unrolled, is shown and annotated below. As you may expect if you've been following this series to this point, the OCSP response starts with the standard TLS record layer header markers but switches to ASN.1 encoding for the actual response itself. The OCSP response consists of two main parts: the signed response, including the response's own validity period (much shorter than that of the certificate), and the certificate that signs the response.
Figure 1 unrolls to a fairly standard TLS content header illustrated below:
16 Handshake
03 03 3.3 (TLS 1.2)
06 4f 1,615 bytes
16 Certificate Status
00 06 4b 1,611 bytes
01 OCSP
00 06 47 1,607 bytes
The TLS prolog is followed by a much longer ASN.1 encoded byte string. I won't go into all the details of ASN.1
encoding, but the gist of it is that it's a tag-length-value encoding; the first byte of each
entry is a tag indicating what sort of data follows. This is followed by a length marker
which itself is variable-length: if the high-order bit of the following byte is a 1,
then that byte (with the length-bit masked off) is the number of bytes which follow and encode
the length of the data. This is followed, of course, by precisely that many bytes of data. The
tags are specific to ASN.1, and the most important/common ones are (in hex):
| 02 | byte string |
| 03 | integer |
| 04 | integer |
| 06 | Object Identifier (globally unique value that acts as a sort of enum) |
| 13 | Printable string |
| 18 | timestamp |
| 30 | structure of other sub-fields |
ASN.1 also permits certain tags to be "explicit" to allow for specification evolution and optional values; there are a few in the OCSP response which I've marked below. This all sounds more complex than it actually is (at least where SSL is concerned); you can probably easily follow through the deconstructed response below and infer the encoding rules even if you're not familiar with them. I've indented below to illustrate the parent-child relationships inherent in the structures and bolded the value parts of the response.
30 82 06 43 1,603 byte sequence follows
0a 01 00 responseStatus 0 [1]
a0 82 06 3c 1,596 byte (custom) sequence follows
30 82 06 38 1,592 byte sequence follows
06 09 2b 06 01 05 05 07 30 01 01 responseType: 1.3.6.1.5.1.5.5.7.48.1.1
(id-pkix-ocsp-basic)
04 82 06 29 1,577 byte sequence of octets [2]
30 82 06 25 1,573 byte sequence
--- Start of OCSP Response bytes
30 81 bf 191 byte sequence (tbsResponseData)
a2 16 EXPLICIT Version DEFAULT v1
04 14 9c 4d 00 99 00 0e 8b b0 01 81 75 a1 ba f0 d0 25 d7 a0 1c 47 responderID key signature (byKey)
18 0f 32 30 31 37 30 38 31 34 31 33 34 31 30 32 5a producedAt: 2017-08-23 03:20:02 (UTC)
30 6f 111 byte sequence (responses)
30 6d 109 byte sequence
30 45 69 byte sequence
30 09 9 byte sequence: CERT ID
06 05 2b 0e 03 02 1a 5-byte OID: Hash algorithm 1.3.14.3.2.26 (SHA-1)
05 00 0 bytes (padding)
04 14 0c 9e 4d 9c 3d ed ef 84 d8 91 e9 72 c7 cf 84 06 bc 19 7b 07 issuerNameHash (of the responder)
04 14 96 de 61 f1 bd 1c 16 29 53 1c c0 cc 7d 3b 83 00 40 e6 1a 7c issuerKeyHash
02 0c 10 e6 fc 62 b7 41 8a d5 00 5e 45 b6 integer Serial Number of the
certificate whose status this is
80 00 (Certificate Status: Good)
18 0f 32 30 31 37 30 38 31 34 31 33 34 31 30 32 5a 2017-08-14 13:41:02 (UTC)
a0 11 explicit tag [0]
18 0f 32 30 31 37 30 38 31 38 31 33 34 31 30 32 5a 2017-08-18 13:41:02 (UTC)
a1 23 explicit tag [1]
30 21 33 byte sequence
30 1f 31 byte sequence (extensions)
06 09 2b 06 01 05 05 07 30 01 02 Id: 1.3.6.1.5.5.7.48.1.2 (id-pkix-ocsp-nonce)
04 12 04 10 f8 68 3d 2c 1f ea 62 ff cc a1 88 9e 51 ef c9 05 (nonce which is an ASN.1
integer inside another ASN.1 integer)
--- End of OCSP Response bytes
30 0d 13 byte sequence
06 09 2a 86 48 86 f7 0d 01 01 0b Signature algorithm (over preceding block):
1.2.840.113549.1.1.11 (sha-256 with RSA Encryption)
05 00 padding
03 82 01 01 257-byte integer
00 35 f2 bf 4c e7 a1 49 0d bf 76 03 45 b6 30 58 6b e3 c0 db 7d c3 3c c6 21 e3 00 4a 68
be 82 3b 9f a2 8e fa 4a f3 42 6d 33 47 a0 a5 5a 24 9d cb 57 53 11 37 78 f9 69 f2 13 44
4d 74 5e 69 87 27 ac 14 5d 93 07 3a a1 c9 3a ec 22 37 77 5b 17 d6 6a f1 f6 65 25 2e 86
b6 b6 0b 6a cf 94 f6 65 1d b1 a8 55 b1 36 80 81 b0 7a 1d ef b5 ba a4 cf e4 82 46 5a 2a
86 82 02 ea af b6 09 50 0c ee 0f c2 37 e3 e3 37 66 65 28 be 27 42 e4 17 63 b1 a8 92 16
04 eb f3 cd 55 51 1e 38 88 70 d9 ed 8b bb 1a b3 df c0 89 95 1b 83 08 6c aa 4e 83 16 ae
d1 40 71 23 43 a2 2a e9 81 ba 87 0d a2 36 d9 70 82 c6 88 34 9b 55 4d 62 a9 01 da f0 79
f2 e3 1e 33 24 84 4b 17 5b 5c 81 78 c3 fb 28 4e 79 a7 26 fd 4e fd 27 42 b3 45 67 c7 17
5a 95 85 0e 67 ff be 26 d2 5f d3 48 ea bb 44 6e 4a b1 d6 ca 9f 76 17 cb 36 (RSA signature) [3]
a0 82 04 4b 1,099-byte (custom) sequence of certificates
30 82 04 47 1,095-byte sequence
30 82 04 43 1,091-byte sequence
--- Start of certificate
30 82 03 2b 811-byte sequence
a0 03 Explicit tag
02 01 02 Cert v3
02 0c 7a 91 5e 55 dd 3d 5b 27 19 d6 eb 27 Certificate serial number
30 0d 13-byte sequence
06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 Signature Algorithm ID: 1.2.840.113549.1.1.11
(sha256 with RSA)
30 66 102-byte sequence
31 0b 11-byte set (Issuer)
30 09 9-byte sequence
06 03 55 04 06 2.5.4.6 (id-at-countryName)
13 02 42 45 BE
31 19 25-byte set
30 17 23-byte sequence
06 03 55 04 0a 2.5.4.10 (id-at-organizationName)
13 10 47 6c 6f 62 61 6c 53 69 67 6e 20 6e 76 2d 73 61 GlobalSign nv-sa
31 3c 60-byte set
30 3a 58-byte sequence
06 03 55 04 03 2.5.4.3
13 33 47 6c 6f 62 61 6c 53 69 67 6e 20 4f 72 67 61 6e 69 7a 61 74 69 6f
6e 20 56 61 6c 69 64 61 74 69 6f 6e 20 43 41 20 2d 20 53 48 41 32 35 36
20 2d 20 47 32 GlobalSign Organization Validation CA - SHA256 - G2
30 1e 30-byte sequence
17 0d 31 37 30 37 31 37 30 39 31 32 35 34 5a notBefore: 17-07-17 09:12:54 (UTC)
17 0d 31 37 31 30 31 37 30 39 31 32 35 34 5a notAfter: 17-10-17 09:12:54 (UTC)
30 81 8e 142-byte sequence (Subject)
31 0b 11-byte set
30 09 9-byte sequence
06 03 55 04 06 2.5.4.6 (id-at-countryName)
13 02 42 45 BE
31 19 25-byte set
30 17 23-byte sequence
06 03 55 04 0a 2.5.4.10 (id-at-organizationName)
13 10 47 6c 6f 62 61 6c 53 69 67 6e 20 6e 76 2d 73 61 GlobalSign nv-sa
31 15 21-byte set
30 13 19-byte sequence
06 03 55 04 05 2.5.4.5 (id-at-serialNumber)
13 0c 32 30 31 37 30 37 31 37 30 30 31 38 201707170018
31 4d 77-byte set
30 4b 75-byte sequence
06 03 55 04 03 2.5.4.3 (id-at-commonName)
13 44 47 6c 6f 62 61 6c 53 69 67 6e 20 4f 72 67 61 6e 69 7a 61 74 69 6f 6e
20 56 61 6c 69 64 61 74 69 6f 6e 20 43 41 20 2d 20 53 48 41 32 35 36 20
2d 20 47 32 20 2d 20 4f 43 53 50 20 52 65 73 70 6f 6e 64 65 72 GlobalSign Organization Validation CA
SHA256 - G2 - OCSP Responder
30 82 01 22 290-byte sequence
30 0d 13-byte sequence
06 09 2a 86 48 86 f7 0d 01 01 01 1.2.840.113549.1.1.1 (rsaEncryption)
05 00 padding
03 82 01 0f 271-byte array
00 padding
30 82 01 0a 266-byte sequence (RSA public key)
02 82 01 01 00 d2 43 97 cf 30 6a e3 d9 52 ce db a7 eb de 05 8b d7 30 13 22 c8
65 a8 26 de 36 27 8a 64 96 fa fa 5f a9 0a 05 17 f5 38 f0 91 aa 59 f5 ce b7 c1
2f 9d c9 7a 7f a3 2d 68 69 af 6b 18 e0 b9 fd 9a ae ed 44 b7 14 b9 a5 d5 fc ff
83 ed 75 17 06 3e 68 1b c1 b9 fc 54 32 2e 92 7e 0f f1 2a 3b bf d6 9f 76 1d 5e
a2 21 64 ec a8 ea f7 0c ca fa 38 83 70 da 65 a6 a2 6d 65 d5 15 94 3e ac ee 56
96 e1 a5 6c 13 07 bb 50 19 36 86 56 81 c5 47 e5 d3 3b 58 9b 07 7f dc b9 fe 06
31 32 55 16 29 44 d1 45 28 6c 64 51 ea 0d 87 36 37 cd 10 40 aa 9d 1d 1c fd c7
6c f0 94 19 41 9e 3e 6c e9 f3 bd bc dd f4 6d 05 d4 65 3b d8 b1 93 80 b7 6e f6
7e 90 90 57 62 81 3f a2 8b 67 45 d5 8c b8 90 98 b9 b3 61 e0 4b 4d f9 46 ce 13
82 7d 81 71 6f 3b 53 e5 04 1c 60 2f d6 12 73 92 98 eb 96 36 1c f7 8d a1 47 eb
61 257-byte modulus
02 03 01 00 01 public exponent (65,537)
a3 81 c7 custom structure 199 bytes
30 81 c4 structure 196 bytes (extensions)
30 1d 29-byte sequence
06 03 55 1d 0e 2.5.29.14 (id-ce-subjectKeyIdentifier)
04 16 04 14 9c 4d 00 99 00 0e 8b b0 01 81 75 a1 ba f0 d0 25 d7 a0 1c 47 subject key
30 1f 31-byte sequence
06 03 55 1d 23 2.5.29.45 (id-ce-authorityKeyIdentifier)
04 18 30 16 80 14 96 de 61 f1 bd 1c 16 29 53 1c c0 cc 7d 3b 83 00 40 e6 1a 7c authority key
30 0f 15-byte sequence
06 09 2b 06 01 05 05 07 30 01 05 04 02 05 00 1.3.6.1.5.5.7.48.1.5 (id-pkix-ocsp-nocheck)
30 4c 76-byte sequence
06 03 55 1d 20 2.5.29.32 (id-ce-certificatePolicies)
04 45 69-byte array
30 43 67-byte sequence
30 41 65-byte sequence
06 09 2b 06 01 04 01 a0 32 01 5f 1.3.6.1.4.1.4146.1.95
30 34 52-byte sequence
30 32 06 08 50-byte sequence
2b 06 01 05 05 07 02 01 1.3.6.1.5.5.7.2.1 (id-qt-cps)
16 26 68 74 74 70 73 3a 2f 2f 77 77 77 2e 67 6c 6f 62 61 6c 73 69
67 6e 2e 63 6f 6d 2f 72 65 70 6f 73 69 74 6f 72 79 2f https://www.globalsign.com/repository
30 0e 15-byte sequence
06 03 55 1d 0f 2.5.29.15 (id-ce-keyUsage)
01 01 ff Critical
04 04 03 02 07 80 digitalSignature only (bitmask)
30 13 19-byte sequence
06 03 55 1d 25 2.5.29.37 (id-ce-extKeyUsage)
04 0c 12-byte array
30 0a 10-byte sequence
06 08 2b 06 01 05 05 07 03 09 1.3.6.1.5.5.7.3.9 (keyPurposeID: OCSPSigning)
--- End of certificate
30 0d (signature over prior certificate bytes)
06 09 2a 86 48 86 f7 0d 01 01 0b 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
05 00 padding
03 82 01 01 00 1b 0d 8b 0b 75 fb 4b 41 4a b8 ca db 3d 73 77 ac 26 b8 21 9a 31 9b 94
76 d2 61 37 38 3f c3 d9 1d 3d 68 5d 30 6c f1 cd 91 2d 43 33 f7 3b 40 86 c3 2f 07
e8 61 25 76 66 c4 0e 59 50 8d 4a 9c 02 fd 21 db ad 80 51 0e 87 4c fd 9e 04 e7 7c
cc f3 34 a1 4a 27 34 c7 59 9f 78 fe 7a 43 a2 28 3d 92 95 50 a0 fc 1a 95 75 27 a9
bb af d1 dd f2 b7 56 23 4c 77 69 84 1f ee 20 e8 7e a8 42 2b e8 ed 7a 01 09 5e 40
b2 3c a4 48 a8 99 2d 36 1b df 75 a7 89 3d ee 72 8a 10 99 23 4b 7f 9d e0 ce 30 88
dd e5 80 fc c4 86 0f d9 5d 4f 34 f3 b7 eb 33 5a d5 1d 80 d4 64 50 a3 fc eb f0 fe
84 26 27 0d ee 86 33 ff cb 2f b5 54 5a df 6d 80 f1 79 d7 60 7c d5 db 84 54 6c 75
43 31 41 4d a2 68 ef 63 eb 6a 0b b7 65 f8 60 86 14 42 71 bb 53 96 6c 62 f3 b1 7b
49 ec ee a4 8f 76 4c 12 b8 57 d2 8d 6b b1 ed 76 ed (257-byte signature) [4]
1: This response status indicates that the OCSP response that follows is valid: not necessarily that the certificate itself is!
2: The specification allows for additional OCSP response types beyond the "basic" response shown here; the preceding responseType value indicates how these bytes should be parsed. As of now, no additional response types have been defined.
3: If you try this yourself, you'll get a different signature; the nonce will definitely be different and the validity periods probably will as well.
4: This signature, on the other hand, will be identical if you download this yourself, at least until October 17, 2017.
You can see that there are two signatures here - one is the signature that verifies the OCSP response in the first place, and the other is the signature that verifies the certificate that verifies the OCSP response. The bytes that make up the OCSP response are the 194 bytes:
3081bfa21604149c4d0099000e8bb0018175a1baf0d025d7a01c47180f32303137303831343133343130325a3
06f306d3045300906052b0e03021a050004140c9e4d9c3dedef84d891e972c7cf8406bc197b07041496de61f1
bd1c1629531cc0cc7d3b830040e61a7c020c10e6fc62b7418ad5005e45b68000180f323031373038313431333
43130325aa011180f32303137303831383133343130325aa1233021301f06092b060105050730010204120410
f8683d2c1fea62ffcca1889e51efc905
whose SHA-256 hash is:
h = 0x6a8203be4fa1d3633ad691e10f29f57952770ebb1e6661bf13d97fe62af12e80
This means that, to produce the signature, the holder of the private key d computed the value s = hd%n and appended it to the message. Given the modulus in the certificate of:
n = 0xd24397cf306ae3d952cedba7ebde058bd7301322c865a826de36278a6496fafa5fa90a0517f538f091a
a59f5ceb7c12f9dc97a7fa32d6869af6b18e0b9fd9aaeed44b714b9a5d5fcff83ed7517063e681bc1b9fc5432
2e927e0ff12a3bbfd69f761d5ea22164eca8eaf70ccafa388370da65a6a26d65d515943eacee5696e1a56c130
7bb501936865681c547e5d33b589b077fdcb9fe06313255162944d145286c6451ea0d873637cd1040aa9d1d1c
fdc76cf09419419e3e6ce9f3bdbcddf46d05d4653bd8b19380b76ef67e90905762813fa28b6745d58cb89098b
9b361e04b4df946ce13827d81716f3b53e5041c602fd612739298eb96361cf78da147eb61
and public exponent e of 65,537, the signature s of:
s = 0x35f2bf4ce7a1490dbf760345b630586be3c0db7dc33cc621e3004a68be823b9fa28efa4af3426d3347a
0a55a249dcb5753113778f969f213444d745e698727ac145d93073aa1c93aec2237775b17d66af1f665252e86
b6b60b6acf94f6651db1a855b1368081b07a1defb5baa4cfe482465a2a868202eaafb609500cee0fc237e3e33
7666528be2742e41763b1a8921604ebf3cd55511e388870d9ed8bbb1ab3dfc089951b83086caa4e8316aed140
712343a22ae981ba870da236d97082c688349b554d62a901daf079f2e31e3324844b175b5c8178c3fb284e79a
726fd4efd2742b34567c7175a95850e67ffbe26d25fd348eabb446e4ab1d6ca9f7617cb36
Can be verified using the public key; this means that se%n should compute back to the hash h of the OCSP response - this works out to:
1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffff003031300d060960864801650304020105000420
6a8203be4fa1d3633ad691e10f29f57952770ebb1e6661bf13d97fe62af12e80
Which, after removing padding, is the ASN.1-encoded sequence:
30 31
30 0d
06 09 608648016503040201
05 00
04 20 6a8203be4fa1d3633ad691e10f29f57952770ebb1e6661bf13d97fe62af12e80
Which includes the hash, as well as the OID of the signature algorithm (included to protect against downgrade attacks).
The second signature is over that certificate - the bytes of that certificate are:
3082032ba003020102020c7a915e55dd3d5b2719d6eb27300d06092a864886f70d01010b05003066310b30090
6035504061302424531193017060355040a1310476c6f62616c5369676e206e762d7361313c303a0603550403
1333476c6f62616c5369676e204f7267616e697a6174696f6e2056616c69646174696f6e204341202d2053484
1323536202d204732301e170d3137303731373039313235345a170d3137313031373039313235345a30818e31
0b300906035504061302424531193017060355040a1310476c6f62616c5369676e206e762d736131153013060
3550405130c323031373037313730303138314d304b06035504031344476c6f62616c5369676e204f7267616e
697a6174696f6e2056616c69646174696f6e204341202d20534841323536202d204732202d204f43535020526
573706f6e64657230820122300d06092a864886f70d01010105000382010f003082010a0282010100d24397cf
306ae3d952cedba7ebde058bd7301322c865a826de36278a6496fafa5fa90a0517f538f091aa59f5ceb7c12f9
dc97a7fa32d6869af6b18e0b9fd9aaeed44b714b9a5d5fcff83ed7517063e681bc1b9fc54322e927e0ff12a3b
bfd69f761d5ea22164eca8eaf70ccafa388370da65a6a26d65d515943eacee5696e1a56c1307bb50193686568
1c547e5d33b589b077fdcb9fe06313255162944d145286c6451ea0d873637cd1040aa9d1d1cfdc76cf0941941
9e3e6ce9f3bdbcddf46d05d4653bd8b19380b76ef67e90905762813fa28b6745d58cb89098b9b361e04b4df94
6ce13827d81716f3b53e5041c602fd612739298eb96361cf78da147eb610203010001a381c73081c4301d0603
551d0e041604149c4d0099000e8bb0018175a1baf0d025d7a01c47301f0603551d2304183016801496de61f1b
d1c1629531cc0cc7d3b830040e61a7c300f06092b060105050730010504020500304c0603551d200445304330
4106092b06010401a032015f3034303206082b06010505070201162668747470733a2f2f7777772e676c6f626
16c7369676e2e636f6d2f7265706f7369746f72792f300e0603551d0f0101ff04040302078030130603551d25
040c300a06082b06010505070309
whose SHA-256 hash h' in turn is:
0x18e51f5a2f2ef472f7e5320340a39ca8bae54cd5ffcb43cb5469dc0854c22a5e
The signature of this certificate (at the very bottom) is:
s' = 0x001b0d8b0b75fb4b414ab8cadb3d7377ac26b8219a319b9476d26137383fc3d91d3d685d306cf1cd91
2d4333f73b4086c32f07e861257666c40e59508d4a9c02fd21dbad80510e874cfd9e04e77cccf334a14a2734c
7599f78fe7a43a2283d929550a0fc1a957527a9bbafd1ddf2b756234c7769841fee20e87ea8422be8ed7a0109
5e40b23ca448a8992d361bdf75a7893dee728a1099234b7f9de0ce3088dde580fcc4860fd95d4f34f3b7eb335
ad51d80d46450a3fcebf0fe8426270dee8633ffcb2fb5545adf6d80f179d7607cd5db84546c754331414da268
ef63eb6a0bb765f86086144271bb53966c62f3b17b49eceea48f764c12b857d28d6bb1ed76ed
This signature, however, was generated by the issuer of that certificate which is listed as "GlobalSign Organization Validation CA - SHA256 - G2". If you recall from my discussion of the certificate exchange, this was the signing certificate of the website's certificate, whose public key modulus was:
n' = 0x00c70e6c3f23937fcc70a59d20c30e533f7ec04ec29849ca47d523ef03348574c8a3022e465c0b7dc9
889d4f8bf0f89c6c8c5535dbbff2b3eafbe356e74a46d91322ca36d59bc1a8e3964393f20cbce6f9e6e899c86
348787f5736691a191d5ad1d47dc29cd47fe18012ae7aea88ea57d8ca0a0a3a1249a262197a0d24f737ebb473
927b05239b12b5ceeb29dfa41402b901a5d4a69c436488def87efee3f51ee5fedca3a8e46631d94c25e918b98
95909aee99d1c6d370f4a1e352028e2afd4218b01c445ad6e2b63ab926b610a4d20ed73ba7ccefe16b5db9f80
f0d68b6cd908794a4f7865da92bcbe35f9b3c4f927804eff9652e60220e10773e95d2bbdb2f1
whose signature validation (s'e%n') is:
0x1ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
fffffffffffffffffffffffffffffffffffffffffffffffffff003031300d0609608648016503040201050004
2018e51f5a2f2ef472f7e5320340a39ca8bae54cd5ffcb43cb5469dc0854c22a5e
Or:
30 31
30 0d
06 09 608648016503040201
05 00
04 20 18e51f5a2f2ef472f7e5320340a39ca8bae54cd5ffcb43cb5469dc0854c22a5e
whose last component matches h' as expected. This certificate, in turn, is already trusted by its signature by the root signing certificate which is built into my (and your) browser.
Add a comment:
Completely off-topic or spam comments will be removed at the discretion of the moderator.
You may preserve formatting (e.g. a code sample) by indenting with four spaces preceding the formatted line(s)
