Section 4.1 of RFC 5280 defines the contents of an x509 Certificate. Specifically, two fields are listed (signatureAlgorithm and signature) and defined to contain the same information: AlgorithmIdentifier:

4.1.  Basic Certificate Fields
  The X.509 v3 certificate basic syntax is as follows.
  Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,            <------
        signatureValue       BIT STRING  }
  TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,            <------
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
     <-~- truncated -~->

Later, in Section, signatureAlgorithm is defined as: signatureAlgorithm

The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. ... This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section

And in Section, signature is defined as: Signature

This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate.

This field MUST contain the same algorithm identifier as the SignatureAlgorithm field in the sequence Certificate (Section

My question is: Why must the same piece of information be listed twice?

I could understand wanting to include the Hash algorithm and Signature generation method in the Certificate Data section so it gets included with the signature verification and is therefore not susceptible to changes.

But if that is the case, why list it again between the Certificate Data and Signature sections?

I came across other questions that seem to ask the same thing, but I did not find an answer that specifically spoke to why it is listed twice. Just that it must be listed twice.

  • 1
    I'd be tempted to reply "because X509 is a heap of poo designed by (several) committee" but maybe there is a non-kafkaian answer.
    – Stephane
    Feb 16, 2016 at 7:51

1 Answer 1


I think it's a protection against certain kind of cryptographic attacks called "algorithm substitution attacks".

Please take a look here: Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute (RFC6211)

As briefly explained here: https://www.rfc-editor.org/rfc/rfc6211

In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process.

I think it's exactly what you are looking for :)

Cheers !

Edit: Edited to add the "I think".

Edit 2: Found out that the question is duplicated... From this post: https://security.stackexchange.com/a/24796 Relating the "TBSCertificate.signature" field:

There doesn't seem to be much use for this field, although you should check that the algorithm identifier matches the one of the signature on the cert (if someone can forge the signature on the cert then they can also change the inner algorithm identifier, it's possible that this was included because of some obscure attack where someone who could convince (broken) signature algorithm A to produce the same signature value as (secure) algorithm B could change the outer, unprotected algorithm identifier from B to A, but couldn't change the inner identifier without invalidating the signature. What this would achieve is unclear).

  • 2
    This is great. And it is almost the answer I am looking for. There is a question that remains: why include it outside of the signature portion? Why not just list it once inside the section of the certificate that is included in the hash for the signature? Wouldn't that be sufficient in preventing someone from modifying the algorithm field? How is listing it twice safer?
    – Eddie
    Feb 22, 2016 at 1:51
  • 1
    Thanks for the link, that is some useful contribution. I've +1'd your answer, because you definitely deserve it. That said, I think the root question still remains unanswered. Why have a Signature Algorithm defined outside of the TBS certificate field at all? Why not only have the one inside the TBS certificate?
    – Eddie
    Feb 22, 2016 at 16:12
  • 1
    Sorry, I just got your point after digging into this... I can't find out why having the dupped signature algorithm outside the signed portion of the certificate. I'll try to find out and I'll reach you back :D Feb 23, 2016 at 3:25
  • 1
    Having the signature algorithm (also) outside the TBS (to-be-signed) structure is probably to make it consistent with similar TBS+signature constructions and not require parsing the TBS structure.
    – astraujums
    May 30, 2019 at 12:47
  • 1
    Without having access to the older specification, it may be historical. If the field was originally unprotected, and then it was discovered that it should be protected, a desire for back compatiblity may have suggest adding a copy of the field rather than moving the field. Feb 20, 2020 at 4:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .