Hi, Edward Chan wrote: > I want to verify that whoever the client is claiming to be, is actually > allowed to connect. However, I don't know where to find this > information in the cert. Are there standard fields where this > information can be found. For example, in the book, "Network Security > with OpenSSL", there is sample code for verifying that the server is > actually who the client connected to. It first looks for the "Subject > Alternative Name" field, then looks for the "DNS" field within that and > checks if this matches the hostname being connected to. If the "DNS" > field is not found, it then checks the "Subject" field for the "Common > Name" field and checks if this matches the hostname being connected to. > Is this the proper way to verify the server cert? And would this work > for most, if not all, server certs the client might receive? Are these > typically the fields that one would use to enter the server's identity?
Well, this way of verifying the servers DNS name seems pretty reasonable. But the main check is not mentioned: You check if the certificate of the server was issued by a certification authority that you trust! It's easy to trick a client to connect to a wrong server (usually using some tricks on DNS), but it should be impossible for an attacker to forge a certificate in a way that it has a valid signature from a trusted certification authority. > I'm looking for something similar for verifying the client? Is there > some set of fields that are typically used to enter the client's > identity? Would the same fields be used for a client cert? Well, client's are usually different. There is nothing that specifies what you (or a certification authority) writes in the certificates of a client. Usually it depends a lot of your application. So what are you doing: Do you authenticate client hosts (so maybe a DNS field or the subject field would contain a host name)? Or do you authenticate users (for example S/MIME email)? Then the subject field would usually contain the full name of a user (and maybe something more to identify a specific user, eg. a certain Adam Smith and not any Adam Smith that might exist...). For many secure applications you would just create an own certification authority and issue certificates yourself. Then you would simply just trust this single certification authority and you would not even need to check for the clients (or users) name that is in the certificate. If you trust some CAs that issued more certificates than the user certificates that you want to accept, you have to know what's in there and check for the fields in the certificates. A CA might issue certificates for your organization with the O field (organization) of your company, so this might be sufficient to be checked. So there is nothing that you can rely on for every certificate in the world, you have to know how the certificates that you want to accept look like. And not to forget: First check if the certificate is valid (valid signature from a CA that you trust, not expired, not revoked), then check the contents. Apache/ModSSL uses regular expressions to check the contents of the certificates, so you can configure Apache to check nearly any fields of the certificates DN (Organization, Organizational Unit, Subject, State, Location, Country, ...). > Thanks in advance for taking the time to help out a rookie :) Well, hopefully this helps a bit. Cheers, Olaf -- Dipl.Inform. Olaf Gellert INTRUSION-LAB.NET Senior Researcher, www.intrusion-lab.net PKI - and IDS - Services [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
