Certificates are signed. When a server authenticates clients through certificates, the following three things happen:
The client demonstrates mastery of the private key corresponding to the public key which is contained in its certificate. This part happens within SSL; as part of the protocol, a signature is computed by the client over a challenge from the server. You don't have to care about that because the SSL library you use already does it.
The server validates the certificate. Validation is about making sure that the certificate contents are genuine. To validate a certificate, the server verifies the signature on the certificate, with regards to its issuing CA public key. The CA public key is itself obtained through the CA certificate, which has to be validated as well, and so on. This process ultimately binds to a public key known a priori, called a trust anchor or root CA.
The Apache SSLCACertificateFile and SSLCACertificatePath directives are used to configure which root CA your server will use.
The server decides whether the authenticated user should be granted access or not. This is what Apache's SSLRequire directive is about: a filter on authenticated identities.
The first step is the method by which the server makes sure that the client is "whoever owns public key Kp" (as found in the sent certificate). Second step is the mechanism which reveals to the server the identity I of the owner of Kp. First and second step together give to the server some guarantee about the identity of the client. Now that the server knows who is calling, the server must still verify that the caller is indeed allowed to do the call. If we want to use strict terminology, the first two steps are authentication per se, while the third step is authorization.
- The client is Bob.
- The private key is Bob's face.
- The certificate is Bob's ID card.
SSLRequire directive is the list of expected guest, within the hands of the security guard.
Bob demonstrates ownership of is face by virtue of that face being firmly attached to his body (the guard checks that the face is not a mask); that's the first step.
The security guards inspects the ID card, concludes that the card is genuine (we assume here that ID cards cannot be falsified), and that the photo on the ID card matches the face of the individual currently standing in front of him. Since Bob's name appears on the ID card, the security guard now knows that he is talking to the genuine "Bob". That's the second step.
Then the security guard checks whether his list of allowed guest contains Bob's name. If it does, he will let Bob in. Otherwise, he will shoo Bob away.
Dave, a party crasher, wants to get pass the security guard. To achieve that, he has to break through one of these steps: either get a fake Bob face (with a mask so perfect that the guard will be fooled), or get a fake ID card (with Dave's face but Bob's name), or alter the guard's list (simply adding his own name to the list). Going back to the Apache server, this means either stealing the client private key (e.g. by cryptographically breaking it -- good luck with that !), obtaining a fake certificate (which entails bribing or hacking one of the CA which Apache has been configured to accept), or altering Apache's configuration (its
SSLRequire directive). Since altering Apache's configuration means that Dave already has root access to the machine, this is usually not a relevant attack.
Knowing Bob's name is not sufficient for Dave. THAT is the answer to your question: no, knowing what to put in a fake certificate (the issuer and subject DN required by
SSLRequire) does not allow crafting a fake certificate; the attacker still has to corrupt some CA so that he gets his certificate signed (in a way that the server accepts).