Investigations identified several recurring causes for certificates being unavailable to candidates despite server-side generation. Technicians re-pushed records to DCWeb using the system push/Force Cert path; successful pushes triggered DCWeb syncs and produced the missing download links. Some Force Cert attempts returned errors or did not update DCWeb; those cases required alternate pushes or escalation to DCWeb support, and occasional links appeared later without detailed logs. Where Enquiry showed certificate numbers but users experienced access errors or link failures, incidents were escalated to DCWeb support for investigation. Historic or exceptional records that could not be pushed into DCWeb were produced in-house and routed to the replacement-certificate owner for manual handling. OASIS provided a Force Cert option that could generate charged digital reprints, but many legacy/school/bridge certificate templates were not yet available in AST/DCWeb, so some reprints still required physical printing from the warehouse. A duplicate certificate association in OASIS prevented adding a new CPCM mapping; removing the duplicate resolved the association and the remaining mapping was verified. Certificate association changes applied only to future completions; existing completions had to be pushed to DCWeb manually.

The Certificate Name field in Oasis was updated with the required special characters (copy/paste from Word where needed); after a short propagation delay (~10 minutes) the characters appeared on MyLIBF/downloadable certificates and subsequent DCWeb checks confirmed the change was not reverted. For incorrect chairman signatures, the new signature asset was uploaded to LetterWriter, and the CERTHE certificate template was edited (the conditional paragraph 'Signature 2' was changed) so that generated CERTHE certificates used the new chairman signature; QUALCERT had already been updated. For very old or ambiguous records that could not be pushed into DCWeb, the certificate production was handled in-house after escalation to the replacement-certificate owner.

A range of certificate issuance, renewal and notification issues were resolved by issuing or replacing the required certificates and securely packaging and delivering private keys and associated intermediate/CA bundles to partners. Wildcard certificates were generated or renewed (for example .iu-healthuniversity.de and .iubh.de); in the iubh cases the renewed wildcard was deployed to MX1 and helpdesk and examined on a campusvps/mail instance that was determined not to require the certificate, and recipients were informed where wildcard scope did not cover unrelated domains. Certificates and private keys were documented in Inventory360 when requested and DNS CNAME records were coordinated with the responsible DNS owners. Mail/TLS problems were fixed by deploying the certificate to /etc/ssl/private on the mail host, restarting Postfix and verifying the SMTP TLS certificate and successful test email. Expired web/TLS errors caused by lapsed licenses were resolved by renewing the licenses and restoring valid certificates. vCenter appliance self-signed certificates were renewed by running the appliance certificate-renewal command over SSH. Imminent SSO certificate expiry was addressed by creating and replacing the Entra ID SSO certificate (new cert issued 2025-06-18), exporting it and supplying it to the partner who uploaded and accepted it. Unexpected AWS Certificate Manager domain-validation approval notifications were routed to the correct staff by updating the webmaster/approver distribution so ACM emails reached responsible approvers.

Multiple certificate failures were resolved with targeted actions based on the fault observed. For hardware token and machine-certificate authentication failures: a YubiKey was reset and re-enrolled which restored its certificate credentials, and machine-certificate authentication was restored after restarting the RADIUS server and restarting the affected domain controller hosts. For S/MIME/import failures: a defective .pfx file that would not import into macOS Keychain was reissued and resent (with password); the user imported the new .pfx into Keychain Access (visible under login → "My Certificates") and configured S/MIME in Outlook. For S/MIME provisioning/onboarding: an S/MIME certificate was provisioned and installed on the user’s IU Windows notebook and the delivery/install method was tested and scheduled. For Kerberos/AD mapping warnings: investigation identified that the KDC logged that a valid user certificate could not be mapped to a user securely; the certificate was flagged for explicit mapping or replacement (explicit mapping or key-trust mapping was recommended in the logs). For domain-controller certificate-based-authentication errors after KB5014754: investigation found required registry keys on DCs were not set and the Intune Certificate Connector version requirement was checked; remedial work identified the missing registry settings and server restarts were used as part of remediation where applicable. For smart-card access errors encountered during Microsoft 365 install: the user was instructed to install Microsoft 365 from the Company Portal (Unternehmensportal); the install via Company Portal completed and the ticket was closed with guidance to reopen if license or access issues persisted.

The SPS submission was investigated and multiple fraud indicators were identified: the supplied SPS claimed a 5‑year validity despite SPS being annual only, the FCA number was omitted from the certificate, the passport date of birth did not match any LIBF record for the named individual, and the supplied FCA link resolved to a different person (Paul Nicholas Morris, M80650), indicating likely misuse of an unauthorised firm name. In the Credly badge case historical email and configuration logs were reviewed and an incorrect badge-association configuration was found for a roughly one-hour window on 21 Dec 2022; that misconfiguration explained the unexpected Fellow badge appearance and subsequent expiration state in Credly.