Recognition Display TLS Certificate Chain Audit for School Kiosks

Quick answer: A recognition display kiosk passes the TLS certificate chain audit when three conditions are simultaneously true. First, running openssl s_client -connect <platform-host>:443 -showcerts </dev/null from a test workstation returns a chain of at least two certificates — the server’s leaf certificate and at least one intermediate CA certificate — with Verify return code: 0 (ok) at the end of the output. Second, the same command run from the kiosk hardware (or a device that matches its OS and TLS library version) returns the same Verify return code: 0 (ok), confirming the kiosk’s local trust store can build a trusted path to a recognized root CA without relying on AIA (Authority Information Access) auto-fetching. Third, the chain’s intermediate and root certificates are verified not expired and not revoked, distinguishing a chain-completeness pass from a misleading “valid chain, expired leaf” state that produces an entirely different error class.

A school recognition display kiosk must validate the full TLS certificate chain using its own OS trust store — confirming that the server's leaf certificate, intermediate CA, and root CA are all present and in the correct order

What a TLS Certificate Chain Is and Why It Matters for School Kiosk Deployments

Every TLS certificate presented by a web server is issued by a certificate authority. That CA’s own certificate is signed by another CA — either another intermediate CA or a root CA that is embedded in the operating system’s trust store. The ordered sequence of certificates from the server’s leaf certificate up to a trusted root is the TLS certificate chain, and a valid TLS connection requires that this chain be complete and verifiable.

A complete chain for a school recognition platform typically contains three certificates:

1. The leaf certificate — issued specifically for the platform’s domain, containing the public key the server uses to authenticate itself and establish the encrypted session. This is the certificate most schools think of when tracking “the certificate” — it carries the domain name and the expiration date that calendar reminders are set for.

2. The intermediate CA certificate — issued by the root CA to an intermediate certificate authority, which in turn signed the leaf certificate. Intermediate CAs exist because root CA private keys are kept offline for security; intermediate CAs are the day-to-day issuers. Many modern CAs use multiple intermediate layers.

3. The root CA certificate — the self-signed certificate of the root certificate authority, embedded in the operating system’s trust store. A TLS library builds trust upward: leaf → intermediate → root. If the root is in the trust store, the chain is trusted.

Where school kiosk deployments diverge from typical browser behavior: Modern desktop browsers implement a fallback mechanism called AIA fetching, which uses the Authority Information Access extension in the leaf certificate to download any missing intermediate certificates over HTTP. If a web server neglects to send an intermediate certificate in its TLS handshake, Chrome, Firefox, and Edge will typically retrieve it automatically, and the user sees no error. A school recognition kiosk running an older embedded OS, a locked-down environment that blocks outbound HTTP to unfamiliar hosts, or a stripped-down TLS library without AIA fetching will not perform this fallback. The connection fails, the display shows a TLS trust error, and from the kiosk’s perspective the content platform is simply unreachable — even though the identical platform URL works perfectly in any desktop browser on the same network.

This is why a TLS certificate chain audit is a distinct procedure from checking whether a certificate has expired. Expiration is visible immediately in browser developer tools and produces a specific, clearly named error. An incomplete chain in a kiosk context may appear as a generic connection failure that triggers a full connectivity investigation — DNS, firewall rules, proxy configuration — before anyone thinks to examine the chain structure on the server.

How an Incomplete Certificate Chain Differs from Certificate Expiration

The most important diagnostic skill for school IT teams managing recognition display kiosks is recognizing which HTTPS failure class they are dealing with. An incomplete certificate chain and an expired certificate both prevent HTTPS connections, but they produce different errors, require different fixes, and have completely different remediation timelines.

Key distinction for school IT teams: An incomplete chain error (verify error:num=20) means the server is failing to provide all the information the kiosk needs to build trust. The kiosk hardware is not broken; the server configuration is. Fixing it requires the platform vendor or server administrator to update the TLS configuration to include the full certificate chain — no action is needed on the kiosk itself. An expired certificate error (verify error:num=10) means a certificate needs to be renewed — a different workflow with a different owner and timeline. Running the audit steps in this guide identifies which failure class is present before any remediation work begins.

Pre-Audit Preparation: Information to Gather Before the Chain Audit

Collect the following information before running the audit commands. Accurate inputs reduce errors and make the audit results easier to interpret and document.

The TLS inspection check is particularly important for school networks. Many schools route HTTPS traffic from all devices — including recognition display kiosks — through a security appliance that terminates the TLS session, inspects the content, and re-encrypts it with a locally issued certificate. From the kiosk’s perspective, every HTTPS connection appears to come from the inspection appliance, not the actual platform server. A chain audit run from a test workstation on the same network path will see the appliance’s chain, not the platform’s actual chain. To audit the platform’s chain directly, run the audit from a network segment or device that bypasses the appliance, or add the platform’s domain to the inspection bypass list before auditing.

Step 1: Inspect the Certificate Chain Using OpenSSL

The primary tool for a recognition display TLS certificate chain audit is OpenSSL’s s_client command with the -showcerts flag. This flag instructs OpenSSL to print every certificate the server sends in the TLS handshake — without it, OpenSSL prints only the leaf certificate, making chain-completeness invisible.

Run the following command from a test workstation with direct access to the platform endpoint, outside any TLS inspection path:

openssl s_client -connect <platform-host>:443 -showcerts </dev/null 2>&1

What to look for in the output:

The output will contain one or more PEM-encoded certificate blocks, each beginning with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE-----. Count the number of certificate blocks:

• One block: The server is sending only the leaf certificate. The chain is incomplete — intermediate CA certificate(s) are missing. A kiosk without AIA fetching will fail to trust this connection.
• Two blocks: The server is sending the leaf certificate and one intermediate CA certificate. This is the most common complete-chain configuration for platforms using modern commercial CAs. Verify that the second block is the intermediate, not a root CA (root CAs should not be sent in the chain — they are embedded in the trust store).
• Three or more blocks: The server is sending the leaf and multiple intermediate certificates, correct for platforms using a multi-tier intermediate CA hierarchy. Confirm the ordering: leaf first, then intermediate(s) from closest to the leaf up toward the root.

The critical line to check is at the bottom of the output:

Verify return code: 0 (ok)

Any non-zero verify return code indicates a chain problem. The most common codes for chain-related failures:

Verify return code: 20 (unable to get local issuer certificate)
Verify return code: 21 (unable to verify the first certificate)

If the verify return code is 0 but only one certificate block is present, the test workstation’s OpenSSL likely performed AIA fetching to retrieve the missing intermediate — which the kiosk hardware may not do. Proceed to Step 3 to test without AIA fetching.

Recognition display kiosks integrated into trophy cases and athletic corridors connect to their content platforms over HTTPS — a complete TLS certificate chain ensures that connection is trusted by the kiosk's own operating system without requiring browser fallback mechanisms

Step 2: Validate the Intermediate Certificates

Once the certificates are visible in the s_client output, extract and examine each one individually. This step confirms the certificates are in the correct order, that the intermediate has not expired, and that the chain links correctly from leaf to root.

Step 2a: Extract individual certificates from the s_client output

Save the full -showcerts output to a file:

openssl s_client -connect <platform-host>:443 -showcerts </dev/null 2>&1 > /tmp/chain.txt

Then use a text editor or command-line tools to separate each -----BEGIN CERTIFICATE----- block into individual PEM files:

• leaf.pem — the first certificate block (matches the platform domain)
• intermediate.pem — the second certificate block
• Additional files for any further intermediate blocks

Step 2b: Examine each certificate

For each PEM file, run:

openssl x509 -in leaf.pem -noout -subject -issuer -dates -ext subjectAltName
openssl x509 -in intermediate.pem -noout -subject -issuer -dates

Verify for the leaf certificate:

• Subject CN or SAN includes the platform’s hostname (or a wildcard that covers it)
• Issuer matches the Subject of the intermediate certificate, confirming the link in the chain
• notAfter date is in the future, confirming the leaf has not expired

Verify for the intermediate certificate:

• Subject matches the Issuer of the leaf certificate
• Issuer matches the Subject of the next intermediate or the root CA
• notAfter date is in the future — intermediate expiration is rare but occurs during CA transitions and is a distinct failure from leaf expiration

Step 2c: Confirm the AIA extension on the leaf

Check whether the leaf certificate includes an AIA extension with a CA Issuers URL:

openssl x509 -in leaf.pem -noout -ext authorityInfoAccess

If this extension is present, desktop browsers will succeed even if the server sends an incomplete chain, because browsers use this URL to fetch the missing intermediate. Kiosk devices without AIA fetching will not. Document the AIA URL for your audit record — if the server is configured to send an incomplete chain, this URL identifies where the missing intermediate can be retrieved to provide to the server administrator.

Step 3: Check Trust Store Compatibility on the Kiosk Hardware

A chain that verifies successfully on a modern test workstation may still fail on the kiosk if the kiosk’s OS does not include the intermediate or root CA in its local trust store. This is a common failure mode on kiosk hardware running older OS builds, embedded Windows versions, or Linux distributions with an outdated CA bundle.

Step 3a: Test without AIA fetching

To simulate a kiosk without AIA fetching, test using only the certificates the server sends, without allowing OpenSSL to make additional network requests. Block outbound access to the AIA URL identified in Step 2c temporarily — using a local firewall rule or an /etc/hosts entry that redirects the AIA hostname to 127.0.0.1 — then re-run:

openssl s_client -connect <platform-host>:443 -showcerts </dev/null 2>&1

Check the verify return code. If it changes from 0 (ok) to a non-zero code when AIA access is blocked, the server chain is incomplete and kiosks without AIA fetching will fail.

Step 3b: Check whether the intermediate CA is in the kiosk trust store

On Windows kiosk hardware:

• Open Certificate Manager: Start → Run → certmgr.msc
• Navigate to Intermediate Certification Authorities → Certificates
• Search for the subject name of the intermediate CA identified in Step 2b

If the intermediate is not present in the local store and the server does not send it in the handshake, the chain will fail to validate on this device regardless of what a workstation shows.

On Linux-based kiosk hardware:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt intermediate.pem

Step 3c: Verify the root CA is in the kiosk trust store

Root CAs are periodically added, removed, or rotated by OS vendors. An older kiosk OS build may not include root CAs that were added to the program after the OS version’s build date. This is particularly relevant for kiosks running Windows 7 or Windows 8 (no longer receiving trust store updates), older embedded Linux builds, or custom kiosk OS images whose CA bundle has not been refreshed in several years.

To identify which root CA the platform uses:

openssl x509 -in intermediate.pem -noout -issuer

The Issuer field of the last intermediate in the chain names the root CA. Search for that root CA name in the kiosk’s trust store using the methods above. If the root CA is not present, the chain cannot be trusted on that device regardless of how complete the chain is — the device requires a trust store update via MDM or OS upgrade.

The DNS search suffix checklist for managed school kiosks that covers kiosk network name resolution complements this step — a kiosk that cannot resolve the platform hostname and a kiosk that cannot trust its certificate both produce connection failures that appear identical until the diagnostic layer is isolated.

School recognition displays in hallways and athletic corridors often run on locked-down kiosk hardware that cannot perform AIA intermediate certificate fetching — the chain audit verifies that the server sends a complete chain so these devices can validate HTTPS trust without additional network lookups

Step 4: Run the Chain Audit Directly on the Kiosk Device

The definitive chain audit for a school kiosk is run from the kiosk hardware itself, using the same TLS library and OS trust store that the display’s content agent uses when connecting to the recognition platform. A test workstation confirms the server’s chain configuration; the kiosk confirms that this specific device can trust that chain.

Step 4a: Access OpenSSL on the kiosk

On Windows kiosk hardware, OpenSSL may be available as part of the recognition platform’s software installation or a network diagnostic package. Check:

where openssl

If OpenSSL is not available, PowerShell provides a built-in alternative that uses Windows’ Schannel TLS library and the Windows certificate store — the same libraries the recognition display software uses:

$request = [System.Net.HttpWebRequest]::Create("https://<platform-host>")
$request.GetResponse() | Out-Null
$cert = $request.ServicePoint.Certificate
Write-Host "Subject: $($cert.Subject)"
Write-Host "Issuer: $($cert.Issuer)"
Write-Host "Expiry: $($cert.GetExpirationDateString())"

If this request throws a WebException citing SSL/TLS or certificate trust errors, the chain is not valid from the kiosk OS perspective.

On Linux kiosk hardware:

openssl s_client -connect <platform-host>:443 -showcerts -CAfile /etc/ssl/certs/ca-certificates.crt </dev/null 2>&1 | tail -5

Using -CAfile /etc/ssl/certs/ca-certificates.crt explicitly tests against the kiosk’s local CA bundle rather than any system-wide auto-discovery, giving a more accurate representation of what the TLS library will do during a real connection.

Step 4b: Record the verify return code from the kiosk

The result from the kiosk hardware is the authoritative audit result. Document:

• OpenSSL version on kiosk: openssl version
• OS version and build: ver (Windows) or uname -a (Linux)
• Number of certificate blocks returned by -showcerts: confirms whether the server sends a complete chain
• Verify return code: 0 (ok) is a pass; any other code is a specific failure requiring investigation

Step 4c: Test the application-layer connection

After confirming the TLS chain validates at the library level, test that the recognition platform’s content endpoint responds correctly at the application layer:

On Windows kiosk:

curl.exe -v https://<platform-host>/health 2>&1 | Select-String "TLS|SSL|certificate|Connected"

On Linux kiosk:

curl -v https://<platform-host>/health 2>&1 | grep -E "TLS|SSL|certificate|Connected"

A 200 OK response confirms both chain validity and application-layer reachability. A TLS error at this layer after the OpenSSL test passes indicates an application-level HTTPS configuration issue rather than a chain completeness problem.

The certificate expiration monitoring guide for recognition displays covers the expiration dimension of certificate health that pairs with this chain audit — running both procedures covers the two most common HTTPS failure modes for school recognition kiosks.

Step 5: Verify the Remediated Chain

After the platform vendor or server administrator updates the TLS configuration to include the complete certificate chain, run the audit again to confirm the fix before returning the display to production use.

Step 5a: Re-run the s_client chain inspection

openssl s_client -connect <platform-host>:443 -showcerts </dev/null 2>&1

Confirm:

• Two or more certificate blocks are now present in the output
• Verify return code: 0 (ok) appears at the end of the output
• The second block’s Subject matches the Issuer of the first block, confirming the chain is correctly ordered

Step 5b: Re-run the kiosk hardware test

Repeat Step 4 from the kiosk device. The verify return code must be 0 (ok) from the kiosk’s own TLS library for the audit to pass.

Step 5c: Confirm the recognition platform connection

On the recognition platform’s management dashboard, verify that the display is reporting an active connection and that content is updating. A successful TLS chain validation that still results in no content updates indicates a problem in the application layer — authentication, content sync configuration, or network routing — rather than the TLS chain.

Step 5d: Document the remediated state

Record the date of remediation, the verify return code after remediation, the number of certificates in the chain, and the identity of the intermediate CA(s) now included. Keep this documentation alongside the certificate expiration dates from your renewal checklist — a complete audit record covers both chain structure and expiration timeline.

The BPDU filter safety check for school switch ports covers another network-layer configuration check that sits alongside TLS chain validation in a complete recognition display deployment audit — both represent pre-production configuration verifications that prevent operational failures affecting displays in athletic facilities and school lobbies.

School administrators reviewing recognition display content depend on the HTTPS connection being fully trusted — a TLS certificate chain audit documents that trust from the kiosk's perspective, not just from a desktop browser's

School Kiosk Certificate Chain Reference Table

Use this table when diagnosing HTTPS connection issues on school recognition display kiosks. The table maps the observed symptom to the most likely chain-related cause, the OpenSSL verify code that confirms it, and the remediation owner.

Troubleshooting Common Chain Audit Failures

Verify Return Code 20: Unable to Get Local Issuer Certificate

Symptom: OpenSSL reports verify error:num=20:unable to get local issuer certificate when connecting to the recognition platform.

Meaning: OpenSSL received the leaf certificate but cannot find the certificate that signed it in either the chain the server sent or the local trust store. The most common cause is the server sending only the leaf certificate without including the intermediate CA certificate in the TLS handshake.

Diagnosis: Count certificate blocks in -showcerts output. If only one block is present, the server is sending an incomplete chain.

Remediation: The platform vendor or server administrator must reconfigure the TLS endpoint to include the full certificate chain. For Apache, this means setting SSLCertificateChainFile or including the chain in the combined PEM file. For Nginx, the combined certificate file (ssl_certificate) must include the leaf and all intermediate certificates in order. For cloud-hosted recognition platforms, this is a vendor-side configuration — the school cannot change it directly.

Verify Return Code 21: Unable to Verify the First Certificate

Symptom: verify error:num=21:unable to verify the first certificate

Meaning: OpenSSL cannot find an issuer for the leaf certificate in either the server’s chain or the local trust store. This can occur if the server sends an intermediate certificate that does not correspond to the leaf certificate’s issuer — indicating a chain mismatch where the server was updated to a new leaf certificate but was not updated with the matching intermediate.

Diagnosis: Compare the Issuer field of the leaf certificate (openssl x509 -in leaf.pem -noout -issuer) against the Subject field of the intermediate certificate (openssl x509 -in intermediate.pem -noout -subject). If they do not match, the server is sending the wrong intermediate for its current leaf.

Remediation: The platform vendor must ensure the intermediate certificate sent in the TLS handshake matches the CA that issued the current leaf certificate. This mismatch often follows a certificate renewal where the leaf was replaced but the server configuration was not updated with the matching chain.

Chain Validates on Modern Workstation but Not on Kiosk

Symptom: Verify return code: 0 (ok) on a test workstation but connection failure or verify error:num=20 from the kiosk hardware running the same command.

Cause: The test workstation performed AIA fetching to retrieve the missing intermediate automatically. The kiosk’s TLS library or OS configuration does not support or allow AIA fetching.

Diagnosis: Check the AIA extension on the leaf certificate (Step 2c). Attempt to access the AIA URL from the kiosk using a browser or curl. If the kiosk cannot reach the AIA URL, AIA fetching is unavailable.

Remediation: This is a server-side configuration issue. The server must be updated to send the complete chain in every TLS handshake. Instruct the platform vendor that AIA fetching cannot be relied upon for kiosk deployments.

Intermediate CA Certificate Has Expired

Symptom: Chain appears complete (two or more blocks in -showcerts) but verify code is 10: certificate has expired, and the expired certificate is the intermediate, not the leaf.

Context: Intermediate CA certificate expiration is relatively rare but occurs during CA organizational changes, root program transitions, or when a CA operates an intermediate with a shorter validity period. Because leaf certificate renewal reminders focus on the leaf’s expiry date, an intermediate expiring on a separate schedule can be missed.

Diagnosis: Run openssl x509 -in intermediate.pem -noout -dates and check the notAfter field.

Remediation: The CA issues a new intermediate certificate. The platform vendor updates the TLS configuration with the new intermediate. This is entirely a vendor-side or CA-side action — the school cannot renew an intermediate CA certificate.

Every person who stops to view a recognition display depends on the content pipeline being uninterrupted — a TLS certificate chain audit is the confirmation that HTTPS trust is established from the kiosk's own perspective, not just from a modern desktop browser

Integrating the Chain Audit into the School Recognition Display Deployment Checklist

A TLS certificate chain audit is most effective as a formal checkpoint in the recognition display deployment process — not a reactive diagnostic run after a content outage. The recommended integration:

Before production go-live:

1. Run Step 1 (openssl s_client with -showcerts) from a test workstation outside TLS inspection to confirm the server sends a complete chain.
2. Run Step 2 to validate intermediate certificates and confirm chain ordering.
3. Run Step 4 from the actual kiosk hardware to confirm the kiosk’s trust store accepts the chain.
4. Document the verify return codes, OS versions, and certificate details in the deployment record.

After any platform update: Re-run Step 1 within 24 hours of a platform vendor certificate update. Certificate changes during routine vendor maintenance are a common cause of post-update chain regressions.

After any kiosk OS update: Re-run Step 4 from the updated kiosk hardware. OS updates can modify the trust store, adding or removing root CAs.

Annual proactive audit: Run the full five-step procedure during summer break maintenance, alongside certificate expiration monitoring review. A complete annual audit covers both chain structure and expiration timeline in one maintenance cycle.

Recognition program managers investing in annual events — fundraisers, athletic induction ceremonies, community celebrations — expect displays associated with those events to be fully operational. Resources covering annual school recognition events and 5K fundraiser programs and school fundraiser recognition guides illustrate the community visibility these events carry. A recognition display that shows an HTTPS trust error during a morning ceremony reflects on the program regardless of whether the cause is a chain misconfiguration or any other technical failure.

Schools hosting ceremonies that celebrate recognition milestones — including graduation and honor events described in guides covering graduation honor displays and school recognition ideas — depend on displays confirmed operational well before the event, not diagnosed on the morning of.

Frequently Asked Questions

What is the difference between a TLS certificate chain audit and a certificate renewal check?

A certificate renewal check tracks expiration dates — specifically whether the leaf certificate’s notAfter date is approaching or has passed. A TLS certificate chain audit checks whether all certificates in the chain are present and correctly ordered so the server’s identity can be verified by the kiosk’s TLS library. A certificate can be perfectly valid months from expiration and still fail a chain audit if the server is configured to send an incomplete chain. Schools should run both procedures: the chain audit before and after deployments and platform updates, and the renewal check on a calendar schedule tied to expiration dates.

How do I tell if my school network uses TLS inspection that would interfere with the chain audit?

Run openssl s_client -connect <platform-host>:443 -showcerts </dev/null 2>&1 and look at the Issuer of the leaf certificate in the output. If the issuer is your school district’s IT department, a security vendor (such as Palo Alto, Zscaler, Forcepoint, or similar), or any organization other than the recognition platform vendor’s CA, TLS inspection is active. The chain you see in that case belongs to the inspection appliance, not the recognition platform. To audit the platform’s actual chain, test from a device or network segment that bypasses TLS inspection for the platform domain.

Can the kiosk be configured to accept an incomplete chain rather than requiring the server to fix it?

Some TLS libraries can be configured to skip chain validation — but doing so removes the authentication that TLS provides and is not appropriate for production school kiosk deployments. Disabling chain validation makes the kiosk’s HTTPS connections indistinguishable from plain HTTP from a security standpoint. The correct fix is always to configure the server to send a complete chain.

Why does the content platform work fine in a browser on the same network but fail on the kiosk?

The most common reason is AIA fetching. Modern browsers retrieve missing intermediate certificates automatically using the AIA URL in the leaf certificate. A kiosk OS or TLS library that does not perform AIA fetching cannot make this automatic retrieval, so the incomplete chain causes a trust failure. The fix is to ensure the server sends the complete chain in the TLS handshake itself so neither browser fallback nor AIA fetching is required.

How long does a TLS certificate chain audit take?

The OpenSSL steps in this guide take 10 to 30 minutes per endpoint from a prepared workstation, including time to extract and examine individual certificate files. Running the audit from the kiosk hardware adds 15 to 20 minutes if remote access (SSH or RDP) is available. For a school with multiple recognition display kiosks of the same hardware and OS model, testing one representative device from each model and OS-version group is sufficient — devices in the same category will exhibit the same trust store behavior.

Does TLS certificate chain configuration change when the platform renews its leaf certificate?

It can. When a platform renews its leaf certificate, the new leaf may be issued by a different intermediate CA than the previous one — especially if the CA has been updated since the last renewal. If the server administrator installs the new leaf without updating the intermediate in the server configuration, the chain becomes mismatched (verify error 21 — the intermediate on the server does not match the new leaf’s issuer). A chain audit run within 24 hours of a leaf certificate renewal catches this regression quickly.

What should we do if the platform vendor says the chain is correct but the kiosk still fails?

Ask the vendor to run openssl s_client -connect <platform-host>:443 -showcerts </dev/null and share the raw output — specifically the number of certificate blocks and the verify return code. If the vendor’s test shows Verify return code: 0 (ok) and your kiosk shows a non-zero code, ask whether the vendor’s test was run from behind a TLS inspection appliance. If the vendor confirms the chain is complete but the kiosk still fails, the failure is likely a trust store issue (Step 3c) — the root CA is not in the kiosk’s OS trust store — rather than a chain incompleteness issue.

Keeping School Recognition Displays Trusted and Current

A school recognition display that fails its TLS chain validation presents the same blank-screen or error-screen outcome as a display that has lost network access or whose content platform account is suspended. From the perspective of a student, family member, or recruit walking past it in a hallway, the cause is irrelevant — the display is not working. From the IT team’s perspective, distinguishing a chain failure from a connectivity failure or an expiration failure within the first few minutes of a support call is the difference between a quick remediation and a lengthy investigation of the wrong layer.

The procedures in this guide give school IT teams the exact commands to confirm chain completeness, identify which certificate is missing or mismatched, and verify that the kiosk’s own trust store can build a trusted path to the platform’s root CA. Combined with a certificate renewal calendar and proactive monitoring, a chain audit completed before each major school recognition event — athletics induction ceremonies, championship celebrations, alumni recognition weekends — ensures that displays are operational when community visibility is highest.