![]() ![]() You seem to be worried that someone could get a client certificate with the server name in it? This is where you'll talk about "man-in-the-middle" attacks, ie where you think you're talking to the real but you're actually talking to an attacker who has a fraudulent cert for that site. If clients can order other clients, that would definitely be bad, but there's not enough info in your question to tell if that's possible. You haven't told us how your servers and clients order certificates from your self-signed CA, but I would hope there are some humans looking at and manually approving each request, or some other process to prevent fraudulent certificates from being issued. It's definitely possible to fool a CA into giving you a certificate that you shouldn't have, but usually you don't use the word "man-in-the-middle" here, you would instead say "issuing a fraudulent certificate". The people who run the CA (maybe actual humans, maybe automated) will verify the details in the CSR, ie if you're requesting a certificate for do you actually own If you're requesting a client cert for are you actually that user? etc.If it's a server, the server admin will create a CSR (certificate signing request) and send that to the CA, or otherwise order a cert.I think you're mixing together two different concepts that use similar words "verifying" or "validating". As far as I know, at least one of those two requirements could be satisfied with pretty much any full name which exists in the world. How you do that is completely up to you, but better make sure that under no circumstances could a Common Name within a client certificate coincide with a Common Name of one of your domains, in case either your CA or some of the TLS-enhanced applications in your infrastructure do not obey RFC strictly.Ī simple way to ensure this is to put the full name of a user into the Common Name and then make sure that each client certificate issued either does contain a space, or doesn't contain a dot. what you put in the Subject field and the nested Common Name field. Now, to start issuing client certificates, you usually have to come up with a naming scheme, i.e. ![]() Here, the Common Name in the certificate equals to *., and Subject contains the Common Name. ![]() For StackExchange it looks like this: Signature Algorithm: sha256WithRSAEncryptionĭNS:*., DNS:, TLS Web Server Authentication, TLS Web Client AuthenticationĪlso, a server certificate contains the domain name of a server in either the Subject or in the Subject Alternative Name X.509 fields. Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*. Issuer: C=US, O=DigiCert Inc, OU=CN=DigiCert SHA2 High Assurance Server CA Take StackExchange certificate as an example: Signature Algorithm: sha256WithRSAEncryption It is common for certificate authorities to include also TLS Web Client Authentication value in a server certificate, which is not bad in and of itself (at least personally I don't see an attack scenario here), but not vice versa. (Note that I'm providing human-readable description of the fields and values, not the actual OID values.) No, it's generally not possible, as long as all the certificates are generated with proper Extended Key Usage (EKU) X.509 field value and all your TLS servers respect RFC.įor a client certificate, EKU should contain the TLS Web Client Authentication value, and for a server certificate, should contain the TLS Web Server Authentication value. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |