CultLib/packages/cultmesh-browser/test/fixtures
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Meta Vens ae8d655cf8 Merge C3 reader branch into release/cultmesh-ts-content
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-19 21:10:42 +02:00
..
chunk-uri-dotnet.fsx cultmesh-browser fixtures: the endpoint list and generator for the .NET chunk-URI expectations 2026-10-19 20:41:59 +02:00
chunk-uri-dotnet.tsv cultmesh-browser fixtures: .NET 10 output for the 201 endpoints 2026-10-19 21:06:22 +02:00
content-https-test-cert.pem C4: loopback HTTPS test credential for the content parity test 2026-10-19 19:40:24 +02:00
content-https-test-key.pem C4: loopback HTTPS test credential for the content parity test 2026-10-19 19:40:24 +02:00
README.md C4: loopback HTTPS test credential for the content parity test 2026-10-19 19:40:24 +02:00

Test fixtures

content-https-test-cert.pem and content-https-test-key.pem are a loopback-only test credential. They sign nothing real: the certificate is self-signed P-256, valid for 127.0.0.1 and localhost, CA:FALSE, serverAuth only, and the key is public on purpose.

They exist for interop/content-https.test.ts. The TypeScript provider serves HTTPS with this pair. The C# suite (CultMeshHttpsContentInteropTests) anchors the certificate with CustomRootTrust, so chain and name validation stay on and no other certificate is accepted. The TypeScript reader trusts it through NODE_EXTRA_CA_CERTS, set on the reader's child process only.

Regenerate (Git Bash needs the MSYS_NO_PATHCONV=1 prefix); no test pins the bytes:

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout content-https-test-key.pem -out content-https-test-cert.pem -days 36500 \
  -subj "/CN=cultmesh-content-https-tests" \
  -addext "subjectAltName=IP:127.0.0.1,DNS:localhost" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "extendedKeyUsage=serverAuth"