AS2 Onboarding with an Incomplete Certificate Chain and Overlapping Signing Certificates
A manufacturer is onboarding a new AS2 partner for signed and encrypted 850/855 traffic over HTTPS with mutual TLS. The partner requires synchronous signed MDNs. The partner sent a leaf certificate issued by its internal CA and a new signing certificate because its old signing certificate expires in 45 days; both have the same subject DN but different serial numbers. After importing the leaf into the truststore, outbound HTTPS to the partner fails with “unable to find valid certification path,” and inbound AS2 signature verification fails intermittently. The partner’s MDN is sometimes unsigned. The manufacturer uses separate keystore and truststore for SSL and AS2. Operations wants to disable certificate validation to restore service during the cutover.
1. Diagnose the SSL and AS2 certificate failures. Which certificates belong in the keystore, the SSL truststore, and the partner profile?
Read the worked answer
The SSL failure is a chain-building problem. A leaf certificate alone is usually not enough for the client to build a path to a trusted anchor; the issuing intermediate or root CA must also be trusted. Importing the partner's leaf into the truststore does not make it a trust anchor unless it is explicitly self-signed or marked as such. For outbound mutual TLS, our own identity and private key belong in the keystore, and the partner's server certificate chain or its issuing CA belongs in the SSL truststore used by the HTTP/AS2 adapter.
The AS2 signature problem is separate. To verify the partner's signature we need the partner's public signing certificate, and to decrypt we need our private key; to sign our own messages and MDNs we use our private key, and the partner verifies with our public certificate. The partner profile should reference the partner's signing certificate explicitly, not rely only on a generic SSL truststore. Because the old and new signing certificates have the same subject DN but different serial numbers, selection by DN alone is unsafe; use the certificate serial number, subject key identifier, or thumbprint to bind the correct certificate to the agreement. The intermittent failure is consistent with one flow using the old certificate and another using the new one while only one is trusted. The unsigned MDN is a partner configuration issue: the partner must be told to sign MDNs, and our side must request and verify a signed MDN.
2. How would you handle the 45-day certificate overlap without causing downtime, and what would you monitor?
Read the worked answer
I would treat the overlap as a controlled dual-trust period. Import the new signing certificate and keep the old one trusted until after the old certificate expires plus an agreed grace period. In the partner profile, allow both certificates for signature verification and make the expected encryption certificate explicit. Then test four paths separately: inbound signed message, inbound encrypted message, outbound signed message, and signed MDN verification. Each path can fail for a different reason, so a single end-to-end success is not enough evidence.
I would also confirm which certificate the partner will use for encryption. If the partner switches its encryption certificate before we have imported it, decryption fails even if signature verification is correct. For our own certificate rotation, publish the new public certificate early and keep the old private key available for decryption of in-flight messages.
Monitoring should include certificate expiration at 30, 14, 7, and 1 days; AS2 MDN signature verification failures; TLS handshake failures; and certificate thumbprint in use for each partner. Log the serial number of the certificate that verified each message so an intermittent failure can be tied to a specific certificate. Remove the old certificate only after the partner confirms cutover and after a clean observation period.
3. Why is disabling certificate validation a poor decision here, and what is a safer emergency step?
Read the worked answer
Disabling validation turns a chain-configuration problem into a trust problem. It would allow any certificate, including one from an attacker who can intercept traffic, to be accepted for a partner connection that carries purchase orders and acknowledgments. It also breaks audit evidence and may violate the partner's security agreement. The immediate cause is known and fixable: an untrusted intermediate or a missing partner signing certificate. Disabling validation does not even solve the AS2 signature failure, because signature verification is a separate trust decision from TLS.
A safer emergency step is to import the missing intermediate CA into the specific truststore used by the AS2/HTTP adapter and to add the partner's new signing certificate alongside the old one. If the partner's certificate is self-signed or issued by an internal CA that cannot be validated conventionally, import that exact certificate as a scoped trust anchor for that partner, with change approval and an expiry review. If an exception is absolutely required, restrict it to the specific partner hostname and certificate thumbprint, log it, and set a short removal date. Test in a non-production environment first. Restarting or reloading the adapter may be needed depending on the release and certificate cache behavior; verify the active certificate chain after the change rather than assuming a hot reload occurred.