rfc5280 appendix b

`wrangler.toml`
to adjust to the updated wrangler
- key added
`compatibility_date`
> https://developers.cloudflare.com/workers/wrangler/configuration/#inheritable-keys
- key removed
`type = "webpack"`
> https://developers.cloudflare.com/workers/wrangler/migration/v1-to-v2/eject-webpack/#migrate-webpack-projects-from-wrangler-version-1

`index.js`
A CA I'm using adds leading '0x00' to a serial number starts with '0x80' in CRL and that prevented S/N match.
9C50B73086B94FB9BCD89795B91720C1
009C50B73086B94FB9BCD89795B91720C1 (->unmatch)

> https://datatracker.ietf.org/doc/html/rfc5280#appendix-B
> https://openssl-dev.openssl.narkive.com/rePxKBOq/openssl-org-3494-possible-sign-bit-bug-in-openssl-1-0-1i-handling-of-128-bit-serial-numbers

I used a workaround below.

```
@@ -62,6 +62,9 @@
revokedSerialNumbers: crlSimpl.revokedCertificates.reduce(
(revokedSerialNums, cert) => {
let serialNum = bufToHex(cert.userCertificate.valueBlock.valueHex)
+ if ((serialNum.length == 34) && (serialNum.startsWith('00'))) {
+ serialNum = serialNum.replace(/^00/,'')
+ }
revokedSerialNums[serialNum] = true
return revokedSerialNums
},
```

Start with index.js and inspect how CRL certificate serial numbers are converted and compared with the request serial number. Read RFC 5280 Appendix B and the linked OpenSSL discussion, then verify the behavior using the provided serial-number example. Also review wrangler.toml against the linked Wrangler migration guidance; done means the configuration is current and the CRL match succeeds for both serial representations.

Written by the indexing model from the issue text.