I am trying to browse to https://servername:portnumber and https://servername.domain.com:portnumber using the same certificate.
How do I configure my openssl.cfg to allow for this? This is the way I configured it [ req ] req_extensions = v3_req # The extensions to add to a certificate request [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment # Include email address in subject alt name: another PKIX recommendation # subjectAltName=email:copy # Copy issuer details # issuerAltName=issuer:copy subjectAltName = @alt_names [alt_names] DNS.1 = server.domain.com DNS.2 = server_name Thanks, Hector L. Jaquez Jr. Data Security Analyst II HQ AAFES, Information Technology Governance W 214-312-4449 BB 214-794-3641 -----Original Message----- From: Jaquez Jr, Hector L. Sent: Monday, December 10, 2012 10:47 AM To: 'Thomas Eckert' Subject: RE: Subject Alternate Names (SANS) I thought I did that by using the DNS.1 and DNS.2 in the openssl.cfg file? How would I go about setting the SANs in the certificate? Thanks, Hector L. Jaquez Jr. Data Security Analyst II HQ AAFES, Information Technology Governance W 214-312-4449 BB 214-794-3641 -----Original Message----- From: Thomas Eckert [mailto:thomas.eck...@sophos.com] Sent: Monday, December 10, 2012 10:01 AM To: Jaquez Jr, Hector L. Subject: Re: Subject Alternate Names (SANS) You want to be able to browse to https://servername:portnumber and https://servername.domain.com:portnumber using the same certificate, right ? If the answer is 'yes' then you also need a certificate that matches those names. The easiest way is to set two SANs, one for servername and one for servername.domain.com . Here, the CN field does not matter anymore (at least for RFC conforming clients). You *should* be able to set it to "spaghetti monster" and still be validated just fine. Reality might be different though (-; All of this is independent of you key size, the locality, the department or whatever other information you put in there. If you ever plan on using this in the wild (even if it's only 'internal') you better set these to some sane values but for testing they don't matter at all. On 12/10/2012 04:51 PM, Jaquez Jr, Hector L. wrote: > So my certificate expired and I had to create a new cert for my > application. Here are the steps I did > > 1. set openssl_conf=c:\openssl-win64\bin\openssl.cfg > 2. Modified config file: >> [ req ] >> req_extensions = v3_req # The extensions to add to a certificate >> request >> >> >> [ v3_req ] >> >> # Extensions to add to a certificate request > 3. Create a new Private key using OpenSSL with 2048 bit strength and encrypt > using des3: > > openssl genrsa -des3 -out c:\ssl\keys\private.key 2048 > > 4. Created CSR file: > > openssl req -new -key c:\ssl\keys\private.key -out > c:\ssl\keys\CSR_File.csr > > <here I had to answer the Country code, Locality, State, Common Name > etc.> When I was asked for the common name I inserted "Server_Name" and not > "Server_name.domain.com" > > 5. Imported CSR in CA to create certificate 6. Installed Cert on CA to > export the P7b and corresponding private key 7. Imported into > application server. > 8. In a browser go to https://servername:portnumber I don't get a > certificate error, but if I go to https://servername.domain.com I get > the certificate error > > So if I go through these steps again to create the .CSR file and insert > "Servername.domain.com" for common name, when I go to > https://Servername.domain.com I don't get a certificate error. However, this > time around, if I browse to https://server.portnumber I will see a > certificate error. > > > > Thanks, > > Hector L. Jaquez Jr. > Data Security Analyst II > HQ AAFES, Information Technology Governance W 214-312-4449 BB > 214-794-3641 > > > -----Original Message----- > From: Thomas Eckert [mailto:thomas.eck...@sophos.com] > Sent: Monday, December 10, 2012 9:25 AM > To: Jaquez Jr, Hector L. > Subject: Re: Subject Alternate Names (SANS) > > On 12/10/2012 02:43 PM, Jaquez Jr, Hector L. wrote: >> Hello All, >> I am having an issue trying to get my server read the SAN entries that >> I have configured in my cnf file. I created a .CSR file (2048) and had our >> PKI folks generate the certificate (.p7b) so that I could import it into my >> application. The application accepts the certificate and the corresponding >> private key. However, when I connect to the application using the FQDN I >> get a certificate error but when I use just the hostname it works fine. >> During the creation of the CSR file I assigned the common name as just the >> hostname. I recreated the CSR file setting the common name as the FQDN and >> when I tried accesing the application with the host name I received a >> certificate error. However, when I tried accessing the application with the >> FQDN it worked fine. It's as though the certificate is not applying the >> SANS I configured in the .cnf file. I researched many forums to try to >> identify what I am missing but I just can't seem to figure it out so I am >> turning to this group. See below for configs that I set in .cnf file. I am >> not sure if I need to run a specific Openssl command to insert this in the >> certificate. I have done this once before and the SANS were read perfectly >> fine so I am not sure what could be the issue. Please help.... >> >> >> [ req ] >> req_extensions = v3_req # The extensions to add to a certificate >> request >> >> >> [ v3_req ] >> >> # Extensions to add to a certificate request >> >> basicConstraints = CA:FALSE >> keyUsage = nonRepudiation, digitalSignature, keyEncipherment >> >> # Include email address in subject alt name: another PKIX >> recommendation # subjectAltName=email:copy # Copy issuer details # >> issuerAltName=issuer:copy subjectAltName = @alt_names >> >> [alt_names] >> DNS.1 = server.domain.com >> DNS.2 = server_name >> >> >> >> >> Thanks, >> >> Hector L. Jaquez Jr. >> Data Security Analyst II >> HQ AAFES, Information Technology Governance W 214-312-4449 BB >> 214-794-3641 > H 7 m >> )z{, RǫJ i Lj)b )z{, )z{, h ^t Ƨj & ^ % > Hi there, > > to be honest I did not fully understand your problem but there is one thing I > noticed that had me confused in the past: You mentioned "I recreated the CSR > file setting the common name as the (...)" > > Note, that according to RFC2818 any certificate with a DNS type > subjectAltName entry is *invalid* if it has no subjectAltName entry that > matches the required host name. This effectively *replaces* the usage of the > 'Common Name (CN)' field (also mentioned in the RFC). Refer to the RFC for > details. > > This was a major pain for me, as I simply did not know it. You might want to > check if you stumbled over this as well. > > Regards, > Thomas >
