Consider the following scenario: You want to securely communicate with a.com and you only trust the VeriSign root certificate.

a.com presents a certificate signed by VeriSign with CN=a.com, so you trust you are indeed communicating with a.com.

Eve has also obtained a certificate from VeriSign for her site b.com. This way, she could create a new certificate with CN=a.com and sign it with the certificate she obtained from VeriSign.

This way, Eve has a certificate for CN=a.com signed by her certificate for b.com, which is signed by VeriSign itself, so you would trust it, too. What is to stop Eve from performing a man-in-the-middle attack?

4 Answers 4


Eve could sign a certificate stating "a.com" as name, with her private key, but Bob's browser will not accept it. When Bob's browser validates a certificate chain, it verifies all signatures, but not only the signature. The complete validation algorithm is intricate; see the standard. In this case, Bob's browser will raise a metaphorical eyebrow when applying check (k) from section 6.1.4: Eve's certificate is a "version 3" certificate, but does not contain a Basic Constraints extension, or its Basic Constraints extension has the cA flag set to FALSE.

In short words, though certification is a kind of power delegation, the power to issue certificates is specified to require explicit delegation, and is not done by default. As @Terry says, commercial CA can grant sub-CA certificates, with the cA flag set to TRUE, but they will charge a lot for that. In fact, they will contractually bind the sub-CA to honour the Certification Practice Statement of the CA (see there for the CPS of Verisign). The contractual obligations include a lot of big money talks with insurances and things like that, so that a sub-CA Eve who would issue fake certificates would be blasted into oblivion by the legal retaliation from Verisign. They make no prisoner.

Things used not to work that way in the past. The first version of X.509 did not support extensions, so clients had to find some other way to verify whether a given entity had the CA power or not. This was inconvenient, because browsers had to choose between embedding a growing list of "allowed sub-CA", or simply trust all certificates with CA power (thus allowing your attack). Note that up to year 2003 or so, there was a bug in Internet Explorer: IE did not check the Basic Constraints extension at all ! When this was discovered, it was promptly patched, of course...

  • Wow, very cool historical context. +1
    – JZeolla
    Commented Apr 3, 2013 at 16:56

You have a misunderstanding on how the certificate signing process works.

In most situations, Eve cannot sign certificates with the certificate she obtains from Verisign. The browser will reject the certificate signed by Eve.

For Eve to sign certificates with the certificate she obtains from Verisign, she has to obtain a certificate containing the Basic Constraint extension with the cA flag set to TRUE. Needless to say, such certificates are a lot more expensive.

  • 1
    So you're saying if Eve had enough money, she could buy a certificate with the cA flag set to true and perform a man in the middle attack?
    – marcoo
    Commented Apr 3, 2013 at 13:09
  • 1
    @marcwho Like @Adam and @Thomas mentioned in their answers, to obtain a certificate with the cA flag set to TRUE, there are a lot of legal and audit processes to go through. Eve certainly could purchase a certificate to perform MITM attacks, but she will be blasted into oblivion with legal actions.
    – user10211
    Commented Apr 3, 2013 at 13:20
  • 2
    @TerryChia: ... if someone notices the attack, that is. In the case of a well-prepared narrowly-targeted attack, that would probably not be the case.
    – thejh
    Commented Apr 3, 2013 at 18:24

Such certificates that could allow Eve to sign a certificate for a.com are sometimes available, though are highly controversial. Some CAs have been less than responsible in the issuance of such certificates (Trustwave, Turktrust, etc.), while others have strict controls (contractual, policies, audits) to prevent the creation of certificates that could be used for MiTM attacks.

GlobalSign, for example, has a product that could be used for MiTM attacks in theory, but contractual and technical requirements and audits prevent such a use (also, in theory). In cases where technical controls aren't possible - the customer would be audited and have the same technical requirements as an independent CA.

The greater risk for creating MiTM certificates is a CA being hacked (either directly of via a trusted reseller). It's happened in the past (Comodo, DigiNotar), and will probably happen again.

As Terry said though, the normal certificates you get from a CA aren't able to sign other certificates.


Basically you cannot sign a certificate using another certificate.Certificates contain only public keys.

  • A certificate is digitally signed by using the private key (and some other parameters depending on the standard that you are using) of the sender.
    • A certificate is signed by VeriSign using their private key. And your browser validates the certificate using VeriSign's certificate (public key).
    • If Eve wants to sign a certificate she would use her private key but the certificate will be treated as invalid by your browser as it does not have Eve's Digital certificate in the list of trusted CAs.
  • "Private key encryption of hash of data" is NOT the definition of a signature. It is a flawed analogy which was first suggested for RSA, but applies to RSA only, not other signature schemes, and even with RSA it does not actually work. In practice, this "explanation" is a surefire way to confuse people. Commented Apr 3, 2013 at 12:40
  • @thomaspornin my apologies...i have made changes to the post.
    – Shurmajee
    Commented Apr 3, 2013 at 18:19

You must log in to answer this question.

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