LEARN. PRACTICE. GROW.Draw the chain that will actually be evaluated
In a fictional fund-application migration, the certificate presented by the application is only one part of the evidence. Draw four positions: approved root R, issuing authority I, optional subordinate authority S and terminal certificate E. Identify which certificates are supplied to build the path and which entity the client already accepts as a trust reference. A certificate supplied by the server does not automatically become that reference. The lab generates these elements as local files. It neither installs them in macOS nor contacts services. In P01 the path is R → I0 → E. In P03 it is R → I1 → S1 → E. The Chain field shows the constructed path. Retain it together with verifier version, input files, requested purpose, expected name and verification time. An “OK” screenshot without these details makes comparison between the team's trial and the application configuration difficult. For a production transition, also ask the technical owner to identify the process that loads the trust store and the chain it presents to its peer. If an instance loads an old file, a laptop trial using a different file does not describe that instance. The acceptance decision must connect the approved configuration to the observed execution.
Delegation depth and client limit
The pathLenConstraint field limits non-self-issued intermediate authorities that may follow the authority concerned. The terminal certificate does not enter that count. In this exercise I0 has pathLen=0: it may issue E directly, but a path adding S0 before E exceeds its limit. Every intermediate in this exercise has different issuer and subject names; we do not use the self-issued-certificate exception. Predict P01, P02 and P03 before execution. The first passes; the second is rejected for depth; the third passes because I1 allows one subordinate. Neither a filename nor the total number of certificates in a bundle replaces a path diagram. A bundle may contain certificates that were not used. P16 applies the local verify_depth=1 limit to the same valid path as P03. This client allows at most one intermediate authority; the path has two. Issuance can respect its constraints while remaining incompatible with the consumer configuration. In a change meeting, distinguish a certification-architecture change from an authorized client change. Increasing a local limit does not remove a signed pathLen=0 in the I0 certificate.
The second name also affects the decision
The fictional project uses api.funds.example. I1 permits names within funds.example and excludes restricted.funds.example. The P04 certificate contains two DNS names: api.funds.example and archive.restricted.funds.example. The first matches the API, but the second falls within the excluded namespace. That exclusion prevents acceptance of this chain even when the second name is not the destination of the tested connection. In the change plan, establish whether the archive alias is actually used. If included by mistake and approved for removal, a newly issued certificate without that alias can resolve this defect. If the archive remains necessary, removing the name without addressing the dependency may interrupt another consumer. The correction must respect the approved use and the authority permitted to issue for each namespace. P05 demonstrates a different failure: api.partner.example matches the requested destination but falls outside the issuer's permitted namespace. Finding the text funds.example somewhere in a name is insufficient; the relationship uses complete DNS labels. These examples avoid internationalized names, wildcards and constraints with a leading dot, so implementation differences do not become hidden premises.
Repair two causes without expanding trust
Consider a candidate with R → I0 → S0 → E and the excluded alias in its terminal certificate. Two independent problems exist: delegation exceeds I0's pathLen and a name violates the exclusion. The verifier's first message is not a guaranteed inventory of every defect. Correcting one cause may make another visible. In the additional excluded0 trial through root R, this OpenSSL version reported both failures, 25 and 48; the following partial corrections isolate the causes. P06 represents correcting only the alias: depth still fails. P07 represents a path with permitted depth while retaining the alias: exclusion still fails. P08 combines the two corrections and passes the requested checks. These three records reuse certificates from other trials to compare hypotheses; they are not three new security mechanisms. In a change committee, record the approved root, authorized issuance architecture and service names that must remain available. Request evidence for each changed condition and a complete-path test. A solution that removes the error by introducing a new trust point changes the scope of the decision and must be recognized as such. A positive result obtained only after changing policy does not establish that the candidate meets the previous policy.
The intermediate promoted to a trust anchor
P09 is deliberately misleading if you look only at the final status. The verifier receives S0 as a trust anchor and allows the path to end there through partial_chain. The evaluated path no longer includes I0. Consequently, restrictions placed in I0 are not part of that path. The terminal certificate containing the excluded alias passes this different configuration. Compare the Chain field with P01 and P03 and identify where each path ends. This trial does not establish that partial_chain is always wrong: a policy may authorize trusting an intermediate directly. It demonstrates that approval based only on R was not established by a trial that switched to trusting S0. The team should identify the change and obtain the appropriate decision instead of describing it as simply restoring a missing file. For the auditor, useful evidence includes the effective trust set and the rationale for its selection. For the project manager, it includes the decision owner, affected consumers and tests to repeat when scope changes. Do not install any certificate generated by this lab in a system trust store.
Accumulated restrictions and rejection cause
In P17 and P18 the upper authority permits funds.example and the subordinate permits only payments.funds.example. The first certificate uses api.payments.funds.example and passes. The second uses api.funds.example and is rejected. The upper authority's wider namespace does not cancel the subordinate's additional restriction. Draw the intersection of permitted namespaces before selecting a new issuer. P10 removes the issuer file from the direct trial. The root is still supplied, but the isolated verifier cannot construct the path. The appropriate action for this defect is to supply the correct intermediate as construction material while retaining the approved root. Installing the intermediate as a trust anchor answers a different question. Use error codes as clues tied to the trial's version and inputs. P02 and P16 both concern depth but have different causes: a signed chain constraint and a local limit. P04 and P05 concern namespaces, with exclusion and permission respectively. Retain stdout, stderr and exit status; looking only for “OK” in concatenated output can hide rejection of other certificates.
What a positive result supports
The worksheet explicitly requests the sslserver purpose and API name in most trials. P11 changes only the expected name and fails. P12 omits purpose and accepts a clientAuth certificate; P13 requests server purpose and rejects the same certificate. P14 changes one signature bit and is rejected. These controls help identify which conditions were actually exercised. P15 requests CRL checking without supplying a CRL and fails because that material is unavailable. The trial does not query OCSP, retrieve a CRL over a network or establish that a certificate is currently revoked or unrevoked. It also does not perform a TLS handshake, test application authorization or measure availability and performance. Write the conclusion with its scope: “This file, chain, root and option set passed on the recorded OpenSSL version at the specified time.” To accept a WebSphere or Kubernetes change, add evidence produced by the relevant consumer using its loaded material and service requirements. The local step helps isolate the problem; the acceptance contract determines the additional trials.
Exercise: prepare the change decision
Download the exercise, confirm Python 3 and OpenSSL 3 are available and choose a new output directory. Run python3 run_lab.py --output attempt-01. The script refuses an existing directory, generates disposable keys and records commands and outcomes. Every repeat generates fresh certificates; compare outcomes and certificate relationships, not identical hashes across executions. Before opening report.json, predict P01 through P10 in a four-column table: path, trust anchor, expected cause and possible repair. Then compare your predictions with the actual results. Explain why P09 passes and why that outcome does not satisfy a policy limited to root R. For P06 and P07 identify the defect that survives the partial correction. Submit a six-line change note: required service and names; authorized root; proposed chain; observed defects; change and decision owner; evidence still needed from the consumer. Finish with the limit of your conclusion. Automated validation checks literal results for this synthetic dataset; the quality of your note depends on recognizing dependencies and trust boundaries.
Exercise files
Python 3 and OpenSSL 3; 18 synthetic trials and PT/EN worksheet.
A fund application passes on a laptop after an intermediate becomes trusted, but this change omits constraints required by the approved architecture.
Common pitfalls
Counting the terminal certificate as an intermediate; ignoring a second SAN; confusing client depth with pathLen; promoting an intermediate without recognizing the changed trust boundary.
Related topics: Public key infrastructure · Technical acceptance and change management
Retain the actual path and parameters; correct each cause and state exactly what passed and what remains to be established.
References
- Internet X.509 Public Key Infrastructure Certificate and CRL Profile · RFC 5280 May 2008, selected sections 4.2.1.9, 4.2.1.10, 6.1.4(g); update/errata screening recorded separately 2026-10-09.
- Certificate verification options · OpenSSL 3.6 documentation retrieved 2026-10-09; exercise executed with OpenSSL 3.6.5 29 Sep 2026.
- Internationalization Updates to RFC 5280 · RFC 9549 March 2024, replaces RFC 8399; selected section 2.3.