LEARN. PRACTICE. GROW.Identify the consumer and failure stage
When WebSphere integration fails after certificate rotation, start by locating the consumer, endpoint, and stage that produced the error. A browser, frontend, JVM, and command-line tool can use different trust material. A successful local test is evidence about that test, not every path. Record reference name, port, observed chain, tool version, and selected configuration. Distinguish local identity loading, handshake, and application response. This separation avoids requesting administrative permissions to fix a chain failure or reissuing certificates when authorization control is simply rejecting an operation that is not allowed.
In-memory handshake laboratory
The lab creates temporary authorities and identities with OpenSSL and uses Python SSLContext and MemoryBIO to exchange TLS messages. These are actual handshakes and, when they succeed, the client sends a small payload received by the server. No TCP sockets are opened and no personal stores are changed. The protocol is fixed to TLS 1.2 to make scope explicit, without presenting it as a universal recommendation. The recorded execution uses CPython 3.13.1 and OpenSSL 3.6.1. These results do not reproduce IBM JSSE, GSKit, IHS, or WebSphere. Keys remain in a protected temporary directory, are not printed, and are deleted at completion.
CA rotation and loaded context
In the first experiment, a client trusting only the old CA accepts the old server and rejects the new certificate. A context containing both approved CAs accepts both states. This demonstrates trust overlap in the fixture without deciding how long the old CA should remain authorized. Another experiment loads old trust, replaces the disk file, and reuses the same context: it still rejects the new server. A context created afterward succeeds. In WebSphere, establish the supported selection and adoption mechanism instead of concluding that Python behavior requires a global cell restart.
Server name and client identity
A trusted chain alone does not answer “is this the expected server?”. The fixture certificate contains partner.example.test, so requesting other.example.test fails name verification. Reimporting the same CA does not change the SAN. In the mTLS trial, the server also requires a client certificate: without a presented identity it rejects the handshake; with a matching certificate and key it accepts it. A separate test tries loading a key that does not match the certificate and fails before any handshake. These results help select the next evidence: name, trust, identity pair, or server requirement. They do not justify permanently disabling validation.
Authentication does not grant every action
Consider a fictional integration reading fund reference data. After mTLS is corrected, the application identifies the client, accepts a read, and rejects a write with 403. If the account requirement is read-only, rejection may be the correct result. Testing should confirm an allowed operation and a prohibited one, with evidence of the applied policy. Do not grant the broadest role merely to obtain successful responses. Also distinguish the component generating the HTTP code, because an isolated 403 does not locate the cause. The lab does not execute application authorization; this part is a decision scenario to rehearse in the actual authorized context.
Rotation and recovery guide
Prepare a matrix of consumers, endpoints, identities, expected trust, and evidence before and after change. Include infrequent clients: absence of a monthly consumer from today’s logs does not confirm its compatibility. Define owners, overlap window, retirement criteria, and recovery to the previous state when still permitted. In the workshop, explain each lab failure without extrapolating to specific WebSphere options. Then write the evidence request for the middleware team: selected configuration, adoption, and a test through the affected consumer. The expected result is functional integration with bounded trust and a clear record of points that still need confirmation.
# ACTUAL TLS LIBRARY LAB: temporary PKI, no TCP sockets
python3 content/labs/was-recovery/run.py --openssl /opt/homebrew/bin/openssl
# Python 3.13.1 + OpenSSL 3.6.1, TLS 1.2 MemoryBIO handshakes
# old trust -> old peer: pass; old trust -> new peer: fail
# overlap trust -> either peer: pass
# No IBM JSSE, IHS, WebSphere, CRL/OCSP or application authorization tested.An updated trust file did not change an existing Python SSLContext. A new context succeeded; WebSphere diagnosis still requires evidence from the actual consumer.
Common pitfalls
Importing into several stores without identifying the one used; overlooking monthly consumers; confusing mTLS with authorization; extrapolating Python reload behavior to IBM JSSE.
Related topics: TLS and administrative access · Artifacts and HTTP path · Maintenance and recovery
Follow the actual call and identify the failure stage. Rotation is established through relevant consumers and operations, with explicit trust boundaries.
Reference: ssl TLS wrapper and MemoryBIO · BigSavant WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30