🔐Public Key & SRI⏱️ 13 min read•Updated November 2026

Subresource Integrity (SRI), X.509 PKI & Public Key Security Runbook

An enterprise security engineering runbook for client-side CDN supply chain verification via W3C Subresource Integrity (SRI), X.509 ASN.1 DER certificate decoding, Public Key Infrastructure (PKI) governance, and modern RFC 5208 PKCS#8 private key standardization.

#Subresource Integrity#SRI#X.509#Certificates#PKCS#8#Public Key Infrastructure#Supply Chain Security#Web Cryptography

1. CDN Supply Chain Vulnerabilities & W3C Subresource Integrity Mechanics

Modern web applications routinely load critical JavaScript libraries, CSS frameworks, and WebAssembly modules from public Content Delivery Networks (CDNs). While CDNs dramatically improve latency and caching efficiency, they introduce an alarming supply chain attack surface: if an attacker compromises the CDN origin, injects malicious code, or tampers with DNS routing, arbitrary JavaScript executes inside the security context of your users sessions. Subresource Integrity (SRI) is a W3C standard that provides cryptographic defense against this threat. When a developer includes the integrity attribute on a script or link tag, the browser intercepts the network response for the asset before parsing or execution, computes a cryptographic digest of the received bytes, and verifies it against the declared hash. If even a single bit differs, the browser drops the file immediately and aborts execution.

W3C Subresource Integrity Script Embed Syntax

<script
  src="https://cdn.example.com/npm/vue@3.4.0/dist/vue.global.prod.js"
  integrity="sha384-3v6zGzZz5Z..."
  crossorigin="anonymous"
></script>

Declares cryptographic SHA-384 digest and mandatory anonymous CORS authorization header.

Attack Vector	Without SRI Protection	With W3C SRI Validation	Defensive Impact
`CDN Compromise`	Malicious payload executes in user browser session	Total Takeover	Browser aborts execution when asset hash mismatches
`DNS Poisoning`	Tampered script served from rogue IP address	Credential Theft	Cryptographic digest fails; script dropped immediately
`Stale Cache Sync`	Outdated or partially written bundle executed	Runtime Corruption	Hash mismatch prevents executing partial script bytes
`MIM Attacks`	Unencrypted or stripped TLS proxy tampering	Data Interception	Single bit flip invalidates SHA-384 base64 signature

2. Cryptographic Digest Selection: SHA-384 vs SHA-256 and CORS Requirements

The W3C SRI specification supports three cryptographic digest algorithms: SHA-256, SHA-384, and SHA-512. SHA-384 is the W3C recommended standard because it delivers 192 bits of collision resistance while offering superior performance over SHA-512 on 64-bit CPU architectures due to shorter output truncation. If a tag declares multiple algorithm hashes, modern browsers evaluate only the strongest algorithm present. To prevent cross-origin data leakage, browsers strictly require that any cross-origin resource with an integrity attribute must also include crossorigin="anonymous". The CDN server must respond with the Access-Control-Allow-Origin header. If the CORS handshake fails, the browser will refuse to load the script even if the hash matches.

Generating W3C SRI SHA-384 Hashes via OpenSSL & Bash

openssl dgst -sha384 -binary library.min.js | openssl base64 -A | sed "s/^/sha384-/"

Generates the standard base64 digest string prefixed with the sha384- algorithm token.

Cryptographic Algorithm	Bit Strength	W3C Standard Tier	Architecture Fit
`SHA-384 Standard`	192 bits collision resistance	W3C Recommended	Optimal 64-bit CPU throughput and quantum resistance
`SHA-512 Standard`	256 bits collision resistance	High Security	Maximum security margin with longer string footprint
`SHA-256 Standard`	128 bits collision resistance	Legacy Fallback	Widely supported but less resilient to future cryptanalysis
`MD5 / SHA-1`	Broken hash algorithms	Strictly Banned	Rejected by modern browser SRI implementations

3. Anatomy of an X.509 Certificate: ASN.1, DER Byte Encoding, and PEM Wrappers

Public Key Infrastructure (PKI) relies on X.509 v3 digital certificates (RFC 5280) to bind cryptographic public keys to domain identities. Under the hood, certificates are hierarchical data trees modeled in Abstract Syntax Notation One (ASN.1) and serialized into binary Distinguished Encoding Rules (DER). To allow binary certificates to be transmitted across text-based protocols (HTTP, TLS handshakes, configuration files), DER bytes are wrapped in Privacy-Enhanced Mail (PEM) containers (RFC 7468). Parsing a certificate involves peeling the PEM boundary, decoding the base64 payload into binary Uint8Array buffers, and traversing the ASN.1 sequence headers to locate the TBSCertificate (To Be Signed) block, Validity dates, Subject and Issuer Distinguished Names (DNs), and the SubjectPublicKeyInfo.

Inspecting X.509 Certificate Hierarchy via OpenSSL CLI

openssl x509 -in certificate.pem -text -noout

Dumps complete ASN.1 decoded certificate tree including serial number, issuer, validity, and SANs.

Certificate Component	ASN.1 Structural Type	Standard Content	Validation Purpose
`TBSCertificate`	SEQUENCE containing core certificate payload	Signed Body	Contains version, serial number, algorithm, validity, and SANs
`Validity Window`	SEQUENCE of two UTCTime or GeneralizedTime values	Timestamps	NotBefore and NotAfter date boundaries for TLS handshakes
`Subject DN`	Name attribute sequence identifying the entity	Identity	Country, Organization, and Common Name domain specifications
`SubjectPublicKeyInfo`	AlgorithmIdentifier and BIT STRING public key	Public Key	The actual RSA or ECC public key used to verify signatures

4. Certificate Expiration Tracking, SANs, and SHA-256 Fingerprinting

Unexpected SSL/TLS certificate expirations remain one of the most common causes of high-profile cloud outages. Proactive monitoring requires inspecting validity timestamps: NotBefore specifies when a certificate becomes valid, while NotAfter specifies the exact UTC expiration threshold. In modern TLS, browsers completely ignore the legacy Common Name (CN) field and strictly enforce Subject Alternative Names (SANs). A certificate must explicitly list all hostnames, subdomains, and wildcard expressions under the SAN extension. A certificate fingerprint is a SHA-256 hash computed over the entire DER binary certificate. SHA-256 fingerprints are the gold standard for mobile app certificate pinning and out-of-band trust audits.

Checking Expiration Date & Extracting SHA-256 Fingerprint

// Check expiry date:
openssl x509 -enddate -noout -in certificate.pem

// Extract SHA-256 fingerprint for certificate pinning:
openssl x509 -fingerprint -sha256 -noout -in certificate.pem

Extracts human-readable expiration dates and 32-byte hex fingerprints for infrastructure monitoring.

Monitoring Metric	Standard Threshold	Critical Alert Level	Operational Impact
`Days to Expiry`	Automated renewal triggered at 30 days	< 7 Days Remaining	Expired certificates trigger red browser interstitial warnings
`SAN Domain Matching`	All subdomains explicitly listed in SAN extension	Missing Hostname	Mismatched domains trigger ERR_CERT_COMMON_NAME_INVALID
`Key Size (RSA)`	Minimum 2048-bit; recommended 4096-bit	< 2048-bit Weak	Sub-2048 bit RSA keys rejected by modern OS trust stores
`Key Curve (ECC)`	NIST P-256 or P-384 / Ed25519 standard	Deprecated Curves	Delivers equivalent 128-bit security with 80% smaller keys

5. Modern Private Key Standards: PKCS#8 vs Legacy PKCS#1 and SEC1 Formats

When generating TLS keypairs or SSH identities, developers encounter fragmented private key formats. Legacy RSA keys use PKCS#1 (delimited by -----BEGIN RSA PRIVATE KEY-----), while Elliptic Curve keys use SEC1 (delimited by -----BEGIN EC PRIVATE KEY-----). Modern cloud infrastructure (Kubernetes, AWS Secrets Manager, OpenSSL 3.0) strongly standardizes on RFC 5208 PKCS#8 (delimited by -----BEGIN PRIVATE KEY-----). PKCS#8 provides a unified ASN.1 wrapper that includes an explicit AlgorithmIdentifier Object Identifier (OID) declaring whether the enclosed key is RSA, Ed25519, or ECDSA. Converting legacy keys to PKCS#8 eliminates format ambiguity across deployment pipelines.

Converting Legacy PKCS#1 / SEC1 Keys to Modern PKCS#8 via OpenSSL

// Convert legacy RSA PKCS#1 or EC SEC1 key to standardized PKCS#8:
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in legacy.key -out pkcs8.key

Wraps raw private key bytes into the universal PKCS#8 ASN.1 envelope with standard OID identification.

Private Key Specification	Header Delimiter	Algorithm Agnostic	Modern Pipeline Standard
`RFC 5208 PKCS#8`	-----BEGIN PRIVATE KEY-----	Universal Envelope	Standard for Kubernetes secrets, Cloudflare, and OpenSSL 3.0
`RFC 3447 PKCS#1`	-----BEGIN RSA PRIVATE KEY-----	RSA Only	Legacy format; lacks explicit algorithm identification
`RFC 5915 SEC1`	-----BEGIN EC PRIVATE KEY-----	ECC Only	Legacy format for NIST elliptic curve private keys
`Encrypted PKCS#8`	-----BEGIN ENCRYPTED PRIVATE KEY-----	Passphrase Protected	Secures keys at rest via AES-256-CBC and PBKDF2 / Scrypt