{{ summaryHeading }}
{{ summaryFigure }}
{{ summarySecondaryLine }}
{{ badge.text }}
Paste or drop PEM, CRT, or CER text; chains are accepted, first block is compared.
Drop certificate PEM, CRT, CER, or TXT onto the textarea.
Paste BEGIN CERTIFICATE REQUEST, NEW CERTIFICATE REQUEST, or bare base64 CSR text.
Drop CSR, PEM, or TXT onto the textarea.
Paste RSA or PKCS#8 PEM; set a passphrase in Advanced when the key is encrypted.
Drop KEY, PEM, or TXT onto the textarea.
Leave blank unless the private key PEM is encrypted.
{{ normalizedPreviewChars }} chars
Choose 12-44 characters; use longer previews when comparing similar pins.
Signal Status Detail Copy
{{ recommendationHeadline }} {{ recommendationHeadline }} {{ recommendationText }}
{{ row.label }} {{ row.status }} {{ row.detail }}
Field Value Copy
{{ row.k }} {{ row.v }}
No details available.
# Signal note Copy
{{ idx + 1 }} {{ note }} 

                

            


        

    

                

                

                    

                        

                            Tags: Devops, Diagnostics, PKI, Security
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                    

                

                

                    

                                                    

                                
                            

                                                    

                                
                            

                                                    

                                
                            

                                                    

                                
                            

                                            

                

            

        
                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
    
A certificate, a certificate signing request, and a private key can all belong to the same TLS job while looking completely different on the page. That is why certificate incidents so often turn into a file-hunting exercise. The names may look familiar, the timestamps may look current, and the folder names may suggest the pieces belong together, yet only the public key identity can answer the real question.

    
This matcher is built for that narrower check. You supply a PEM certificate, optionally add a CSR, optionally add an RSA private key, and the page tells you whether the supplied material points back to the same public key. That matters during certificate renewal, server migration, rollback after a failed cutover, or any handoff where the certificate came from one place and the key material came from another.

    
The result can still be useful when the certificate text changed. A renewed certificate may carry a new serial number, new validity dates, and a fresh issuer signature while still matching the same key pair. The comparison here is therefore about key continuity, not about whether two files are byte-for-byte alike.


    

      
        SSL matcher flow from certificate, CSR, and RSA key inputs to a match result
        A certificate or certificate chain, an optional CSR, and an optional RSA private key feed a shared SPKI fingerprint comparison step that produces match, mismatch, or partial results plus detail output.
        
        
        Certificate or chain
        first certificate block becomes
        the comparison target

        
        Optional CSR

        
        Optional RSA key

        
        
        
        
        
        

        
        Extract public key identity
        build DER SubjectPublicKeyInfo
        hash with SHA-256
        compare the resulting pins

        
        

        
        Result
        
        MATCH
        
        MISMATCH
        
        PARTIAL
        details, signals, JSON, exports
      
    


    
The output is arranged for troubleshooting rather than for certificate theory. You get a headline verdict, a short hint, a details table, a signal list, a JSON view, and export actions for CSV, DOCX, and JSON. That is enough to confirm the right file set before deployment or to capture evidence for the next person in the ticket.

    
A good match is still a narrow result. It does not prove trust, hostname coverage, expiry, revocation state, or chain correctness. It says only that the supplied artifacts expose the same public key identity. Private keys remain sensitive material, so use a trusted browser session and clear the fields when you are done.

  






  

    
Technical Details

    
X.509 certificates and PKCS #10 requests both carry a SubjectPublicKeyInfo structure, usually shortened to SPKI. That structure is the stable common ground across certificate issuance and renewal because it represents the public key itself rather than the surrounding certificate metadata. A private key does not arrive in SPKI form, but an RSA private key contains the numbers needed to reconstruct the matching RSA public key, which lets the page compare it on the same basis.

    
The matcher therefore avoids text comparison and avoids certificate fingerprint comparison. Whole-file fingerprints would change as soon as validity dates, serial numbers, issuer signatures, or request attributes changed. That would hide the much more useful question of whether the same key pair is still in play. By reducing each supplied artifact to one public-key fingerprint, the page can confirm key continuity across a reissue while still flagging a truly wrong key.


    

      
        
          
            PinSPKI
            =
            Base64(SHA-256(DER(SubjectPublicKeyInfo)))
          
          
            match
            =
            all supplied certificate comparisons return the same pin
          
        
      
    


    
That formula matches the public-key pin language used in RFC 7469. The page computes the pin locally from the DER-encoded SPKI and stores it as base64, which is why the result table can compare a certificate, a CSR, and an RSA private key even though the original files look unrelated.


    

      

        
        
          

            Input
            What the page extracts
            Important boundary
          

        
        
          

            Certificate field
            The first certificate block, its subject common name, a key summary, and an SPKI pin
            If you paste a chain, only the first parsed certificate becomes the leaf used for comparison.
          

          

            CSR field
            Subject common name, CSR signature verification state, and an SPKI pin
            A bare request body can be wrapped into a standard CSR text block before parsing.
          

          

            Private key field
            RSA key size summary, encrypted-key flag, and an SPKI pin rebuilt from the RSA public component
            Private-key matching works only for RSA keys, even though certificate and CSR summaries may still show EC public keys.
          

        
      

    


    
The verdict rules are simple. With only a certificate, the status stays PARTIAL because there is nothing else to compare. Add a CSR and the page compares certificate versus CSR. Add an RSA private key and it compares certificate versus key. When both are present, it also reports CSR versus key in the details table. The headline turns into MATCH only when every available comparison against the certificate succeeds. Otherwise it becomes MISMATCH.

    
The CSR check has one extra step. The page verifies the CSR signature before showing the result. A verified request tells you the CSR is self-consistent with its embedded public key, which is what PKCS #10 expects. That still does not mean a certificate authority will issue from it. It only means the request was signed by the holder of the matching private key at creation time.

    
Text handling also matters. Certificates can be concatenated into one textual chain, which is why pasted bundles are common during support work. CSRs are expected to use the CERTIFICATE REQUEST label, and unencrypted or encrypted PKCS #8 private keys use PRIVATE KEY or ENCRYPTED PRIVATE KEY labels. The matcher also recognizes traditional RSA private-key PEM input. All of the parsing and comparison happens in the page, so the tool does not need a server-side helper just to compute the verdict.

  






  

    
Everyday Use & Decision Guide

    
Start with the certificate you actually expect to install. That sounds obvious, but the most common false mismatch comes from pasting a chain in the wrong order. The matcher uses the first certificate block it can parse. If the first block is an intermediate rather than the service certificate, the result will faithfully compare the wrong thing.

    
Next, choose the companion artifact that answers your immediate question. A CSR is the right companion when you want to confirm that the issued certificate still belongs to the request saved during issuance. A private key is the right companion when you want to confirm that the deployment host, backup archive, or restored file set still has the correct key.

    
The input path is flexible enough for hurried operational work. You can paste directly, drag a PEM file into the relevant field, or use the upload control and let the page sort certificate, CSR, and private-key text by its headers. If the CSR was copied without its PEM boundary lines, the matcher can still wrap the request body and try the parse, which often saves time during ticket cleanup.

    
Use extra care with encrypted keys. A successful run means the passphrase opened the key well enough for the page to rebuild the RSA public component and compare it, not that passphrase storage or key handling in the wider system is correct. If the key is not RSA, the private-key comparison lane will stop there, so use the certificate and CSR pair instead of expecting the private-key lane to rescue the check.

    
    
      
  • If the result is PARTIAL, treat it as a quick certificate inspection plus fingerprint lookup, not as a final readiness check.
    • 
      
  • If the result is MISMATCH after pasting a chain, verify chain order before assuming the wrong key was supplied.
    • 
      
  • If CSR Verified is No, do not trust the request just because its common name looks familiar.
    • 
      
  • If you need a handoff artifact, export the table as CSV or DOCX, or save the structured result from the JSON tab.
    • 
    

  






  

    
Step-by-Step Guide

    
    
      
  1. Paste the certificate into Certificate (PEM). If you have a chain, put the intended leaf certificate first.
    2. 
      
  2. Add a request in CSR (optional) when you want to confirm issuance continuity, or add a key in Private key (optional) when you want to confirm deployment continuity.
    3. 
      
  3. Use drag and drop or the upload field if that is faster than pasting. The page will try to route the text to the right field from its PEM headers.
    4. 
      
  4. Open Advanced only if the private key is encrypted, then enter the passphrase and run Match.
    5. 
      
  5. Read the headline and summary hint first. Then open Match Details for the comparison rows and Match Signals for short operational notes.
    6. 
      
  6. Use JSON, CSV export, or DOCX export when you need a record for a ticket, change note, or deployment handoff.
    7. 
    

  






  

    
Interpreting Results

    
The most important habit is to separate identity cues from the real comparison rule. The common name and key summary help you orient yourself quickly, but they do not decide the verdict. The SPKI comparison decides the verdict because that is where the actual public key identity lives.


    

      

        
        
          

            Visible result
            Best first reading
            Useful next check
          

        
        
          

            MATCH
            Every supplied comparison against the certificate produced the same SPKI pin.
            Continue with trust, hostname, expiry, and chain validation using the right tools for those questions.
          

          

            MISMATCH
            At least one supplied artifact does not belong to the certificate at the public-key level.
            Check chain order first, then verify whether the wrong CSR or wrong private key was supplied.
          

          

            PARTIAL
            The certificate parsed, but there was no companion artifact to compare.
            Use the exposed CN, key summary, and SPKI pin as orientation while you locate the CSR or private key.
          

          

            CSR Verified = Yes
            The CSR signature validated against its embedded public key.
            Still confirm that the request names and certificate plan are the ones you intended.
          

          

            CSR Verified = No
            The request parsed, but the self-signature did not verify.
            Treat the CSR as unreliable and regenerate it rather than pushing it forward.
          

        
      

    


    
Warnings deserve attention even when the main word looks positive. A match plus a CSR verification warning means the public keys lined up but the request itself was not self-consistent. An encrypted-key note means the comparison succeeded through the passphrase path and should remind you to double-check how that key will be handled outside this page.

    
The common name is a convenience label, not a trust anchor. Two files can show the same familiar host name and still mismatch because the underlying public keys differ. The opposite can also happen during a controlled reissue: much of the certificate text changes while the key identity stays the same, and that is exactly the kind of continuity this matcher is meant to reveal.

  






  

    
Worked Examples


    
Renewal that reuses the existing key pair

    
You receive a newly issued certificate after renewal and want to confirm it still belongs to the earlier request. Paste the certificate and the saved CSR. If the result is MATCH, the CSR verifies, and the SPKI pins are identical, the key identity stayed the same even though the certificate text itself changed.


    
Migration that copied the wrong key file

    
A service was rebuilt on a new host and now refuses to start with the restored certificate set. Paste the certificate and the private key taken from the new host. If certificate versus key comes back No, the deployment almost certainly picked up the wrong RSA key file or an outdated backup.


    
Ticket bundle with a chain in the wrong order

    
A support ticket includes two certificate blocks, one intermediate and one leaf, pasted into the same field. If the intermediate appears first, the matcher compares the intermediate against the CSR or key and can report a mismatch that looks mysterious at first glance. Reordering the bundle so the leaf appears first usually resolves the confusion immediately.

  






  

    
FAQ:


    

      Does a match prove the certificate is trusted or ready for production?
      
No. It proves only that the supplied artifacts expose the same public key. Trust chain validation, hostname coverage, expiry, revocation, and listener configuration are separate checks.

    


    

      Why can a certificate show an EC key summary while the private-key lane refuses the key?
      
Because the certificate and CSR paths compare public-key material, while the private-key lane is implemented only for RSA private keys. EC certificates and EC CSRs can still be compared against each other through their public keys.

    


    

      Can I paste only the body of a CSR?
      
Yes. If the request body is present but the usual CSR boundary lines are missing, the page can wrap it into standard CSR text before parsing.

    


    

      What happens if I paste just a certificate or certificate chain?
      
The page will still parse the first certificate and show its common name, key summary, and SPKI pin, but the verdict remains PARTIAL until a CSR or private key is supplied.

    


    

      Does the matching operation require sending my key material to a remote helper?
      
No. The comparison happens in the page itself. You should still treat the browser session carefully because certificates, requests, keys, and passphrases are sensitive while they are open on screen.

    

  






  

    
Glossary:

    

      
Leaf certificate

      
The end-entity certificate intended for the service, rather than an intermediate certificate higher in the chain.


      
CSR

      
A certificate signing request containing a subject name, a public key, optional attributes, and a signature made with the matching private key.


      
SPKI

      
SubjectPublicKeyInfo, the standard ASN.1 structure that describes a public key and its algorithm.


      
SPKI pin

      
A SHA-256 digest of the DER-encoded SPKI, shown in base64 so different artifacts can be compared directly.


      
PEM

      
A textual wrapper for certificates, requests, and keys that uses BEGIN and END boundary lines around base64 content.

    

  






  

    
References: