We are in the process of securing our internal servers and there is a requirement of using two factor authentication (SSL client&server certificates and username-password).

One doubt that has come to my mind is if, when enforcing multiple factor authentication, the different factors must be relationed to each other when it is possible.

For example, if I know that some client system will have certificate X and username Y, should I reject a petition that comes with certificate X and username Z (which is valid but would be associated with another system that has certificate K)?

UPDATE: Since I see that the current answers talk about end users (browsers and certificate cards), I would like to emphasize that the communication is between several servers; the users are application users.

I have been browsing through Apache's modules1 and I do not see any straightforward way of implementing, so I do not know if my idea is just not part of the standard implementations and a bit too strict, or I am missing something.

1Admittedly, not my speciality.

  • Just a remark: client certificate on a smart card is alone a strong 2 factor : you must have the card (smth you have) and know the code (smth you know). Commented Dec 19, 2018 at 10:41
  • If not authenticating users, then why do you have both username and password, and certificates?
    – schroeder
    Commented Dec 19, 2018 at 13:14
  • Why are you looking at 2FA for internal servers?
    – schroeder
    Commented Dec 19, 2018 at 13:15
  • @schroeder It is what the IT Security Office has requested (locale is Spain and the data is healthcare data, so security requirements are rather high). To be clear, I am not asking what I have to do (that is what my CPO is for), it is just that I had this doubt and I wanted to check it without making much of a fuss about it at work.
    – SJuan76
    Commented Dec 19, 2018 at 13:39
  • Sure, but context matters, and everyone here is thinking you mean 'users'. As I mention in my answer, your architecture might let you get away with it, but is always comes down to what risks the control is meant to address. You need to ask your security team what these controls are meant to address so that you know if any solution meets the requirement.
    – schroeder
    Commented Dec 19, 2018 at 13:41

2 Answers 2


In some cases of system design, you might be able to get away with blindly accepting tokens, but I doubt it.

Any security control is meant to address risks. If you want to use both a certificate and a separate credential set to authenticate a server, then you do that because it reduces the risks identified.

If you do not correlate the certificate to the credential set, then you reduce the factors to 1.5 instead of 2; any combination will do.

Is this ok? It depends on the risks that you want to reduce. If it does not matter, then it does not matter.

Here's my problem though. If a threat actor has access to the certificate, then the actor can also gain access to the credentials, and vice versa. I'm not sure how adding a factor is a control in the situation, but I also do not know your risk scenarios.


Authentication is about proving the asserted identity. If you receive tokens which are associated with a different identity then you shouldn't authenticate - the token is not proving identity.

(arguably requiring any certificate with specific characteristics adds some value as a second factor to an authentication system, but not nearly as much as matching tokens)

I have been browsing through Apache's modules

This rather implies that you are relying on HTTP authentication as the thing you want the certificate (SSLOptions +StdEnvVars) to correlate with. While this is possible I would strongly recommend against it unless you are exclusively serving static content - it givers the user/browser maker a lot of control over the storage the password at the client and makes things like adding/removing accounts and rotating passwords a lot more difficult.

You must log in to answer this question.

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