証明書チェーン構築・修正ツール
サーバーが送信している証明書を貼り付けてください。PEM、DER、base64、PKCS #7 バンドルのいずれでもよく、順序は問いません。このツールは証明書を正しい順序に並べ、すべての署名と CA の制約を検証し、クロス署名されたパスについて説明します。中間証明書が不足している場合は、証明書内に記載された AIA のアドレスからダウンロードすることもできます。
チェーンの並べ替えと確認はブラウザー内で行われます。不足している中間証明書の取得を指示したときに限り、証明書から取り出した AIA の URL がこのサイトのサーバーに送信され、サーバーがその公開証明書をダウンロードします。貼り付けたバンドルが送信されることはなく、何も保存されません。
What a chain is
A TLS certificate is signed by an intermediate CA, whose certificate is signed by another CA, and so on up to a self-signed root that ships with the browser or the operating system. A client trusts the server's certificate only if it can walk that path from the leaf to one of its roots, checking at every step that the issuer's name matches, that its public key verifies the signature, that it is allowed to act as a CA (basicConstraints with CA:TRUE, and keyCertSign in its key usage), and that every certificate is inside its validity period. RFC 5280 §6 defines that walk; RFC 4158 explains why building the path is the hard part.
Clients have the roots, but not the intermediates. That is why a server must send its leaf certificate and every intermediate, leaf first — the TLS specifications ask for exactly that order. The root is better left out: clients ignore it, and it only adds bytes to every handshake.
What the builder does with your bundle
You can paste the certificates in any order, as PEM blocks, DER files, base64 or a PKCS #7 (.p7b) bundle. The builder parses each one, drops duplicates, and links every certificate to the ones whose subject matches its issuer and whose key actually verifies its signature — names alone are not enough, because two different CAs can share a name. It then walks every path from the leaf upwards and picks the best one: complete paths first, then paths whose root is still valid, then the shortest.
Along the best path it checks what clients check: the signature of every link, CA flags and key usage, path length constraints, extended key usage that would forbid the leaf's purpose, SHA-1 or MD5 signatures browsers stopped accepting, and expiry. It also tells you about the bundle itself — certificates that do not belong to the chain, a bundle out of order, a leaf that is not first, a root included for no reason — and about cross-signing, when the same CA key appears with two different issuers and clients may build different paths.
The output is two blocks of PEM: what your server should send (leaf and intermediates, no root) and the full chain including the root, for tools that want it.
When an intermediate is missing: AIA
The most common chain error on the web is a server that sends only its own certificate. Browsers often hide it: Chrome and Safari download the missing intermediate themselves, and Firefox ships a list of known intermediates. Everything else — curl, Java, Python, Node.js, Go, mobile apps and most server-to-server traffic — fails with "unable to get local issuer certificate" or "PKIX path building failed". A site that works in your browser can still be broken for every API client.
The fix is usually inside the certificate itself. The Authority Information Access extension (RFC 5280 §4.2.2.1) can carry a caIssuers URL where the issuer's certificate is published, as a DER file or a certs-only PKCS #7 bundle. When the builder finds a gap, it lists those URLs, and on your request downloads the issuer, adds it to the bundle and tries again, up to the root.
That download is the one step that does not happen in your browser: AIA URLs are mostly plain http, and their servers send no CORS headers, so a web page cannot read them. The page sends the URL — never your bundle — to our server, which fetches it through the same guarded path every server-side download on this site uses: the address is screened against private and reserved ranges, the connection is pinned to the screened address, redirects are re-checked, only ports 80 and 443 are allowed, and the body is capped. The server passes the bytes back only if they really are certificates, and keeps them for a day so the CA's server is not asked twice.
When it still fails
Some certificates name no AIA URL at all; then the issuer has to come from the CA's repository. An AIA URL can also lead to a different version of the right CA — cross-signed by another root, as Google's intermediates are — which the builder shows as a second path. And a complete chain is not yet a trusted one: whether the root at the end is in your client's trust store, and whether any certificate on the way has been revoked, are separate questions. The certificate decoder takes each certificate apart in full.