On Fri, May 2, 2014 at 7:05 AM, krinalishah <krinali.s...@einfochips.com>wrote:
> > ... > I have created two seperate certificates for my server and client (here > client is a web browser). > Now my question is, when I create .crt certificate signed by CA, via > openSSL, it asks me for Common Name. > What I understand by this field is if I set common name as www.example.com, > than when my https services are enabled on my server, I should be able to > connect to my server by typing > www.example.com as a URL, in web browser's tab (here, this web browser > becomes client). > But this doesn't happen in my case. If I type common name (Given as a > parameter, while creating certificate) in web browser, it shows me an error > of "Can't Display This Page". > Can you help me on what should be this common name field, while creating > certificates for both server and client? > If its PKIX, then placing a DNS name in the CN field is deprecated. You should set the CN to something like "eInfochips, LLC", and you should place you DNS names in the SAN. That means the SANs would have "einfochips.com", "*.einfochips.com", etc. For references, see the CA/Browser Baseline Requirements ( http://cabforum.org/baseline-requirements-documents/), section 9.2.2: 9.2.2 Subject Common Name Field Certificate Field: subject:commonName (OID 2.5.4.3) Required/Optional: Deprecated (Discouraged, but not prohibited) Contents: If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1). Also see RFC 6125 (http://tools.ietf.org/html/rfc6125), section 6.4.4: 6.4.4. Checking of Common Names As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client. Therefore, if and only if the presented identifiers do not include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client, then the client MAY as a last resort check for a string whose form matches that of a fully qualified DNS domain name in a Common Name field of the subject field (i.e., a CN-ID). The RFCs are rather sloppy, and they allow just about anything. Just take a look at the mashup of key usage. The CA/Browser Baseline Requirements is probably the target to shoot for because that's how CAs issue certificates for the web. If you are running a private PKI, then do whatever you feel like. Jeff
