As some additional info, I am suspecting this may be an issue with my
config file.

I am using the same config file I used to set up my certificate authority,
which has under [ req ] a couple of values plugged in - for one, prompt=no,
because I didnt want it to prompt me for values. It also has a value filled
in for distinguished_name which points to a section called [
ca_distinguished_name ] that has the values for commonName, etc, that seem
to be getting put into my CSR.

Could this be the issue? Do I need to have a separate config file for
generating my CSRs than I used for generating my CA cert?

Thanks

On Fri, Oct 12, 2012 at 11:22 AM, Derek Cole <derek.c...@gmail.com> wrote:

> So I think you were right. I used a command to view the CSR that I
> generated with the following:
>
> openssl req -new -nodes -subj "/CN=www.myserver.com" -out /tmp/file.csr
> -keyout /tmp/privkey.csr -config /my/openssl.cnf
>
> when I do this though, I noticed that my subject line, which I view with
>
> openssl req -noout -text -in /tmp/file.csr -config /my/openssl.cnf
>
>
> It seems like the file is getting created with the common name in the
> config file intsead of the one I pass it. Does it not overrride the config
> file?
>
> Thanks
>
>
>
>
> On Thu, Oct 11, 2012 at 7:55 PM, Dave Thompson <dthomp...@prinpay.com>wrote:
>
>> >From: owner-openssl-us...@openssl.org On Behalf Of Derek Cole
>> >Sent: Thursday, 11 October, 2012 19:03
>>
>> >i have a server that is running a custom app that can accept
>> >a SSL connection. I generate a cert on each server, that is
>> >signed by my own CA. I tested whether this worked or not by
>> >using the openssl s_client and s_server commands, and it actually
>> >worked to connect to the server using those commands. I started
>> >the server with a PEM file that contained the signed cert request,
>>
>> Nit: it contains the cert, and privatekey. A cert is NOT a signed CSR.
>>
>> >as well as the private key for that cert request. This allowed me
>> >to start the server with
>> >       openssl s_server -accept 443 -cert myfile.cert
>>
>> Note that will support connection at the SSL level, but not give
>> an HTTP response unless you type it by hand (which is hard to do).
>> Add -www to support minimal requests from browsers.
>>
>> >       and on the client side <snip: s_client okay>
>>
>> >I installed my_server_cert.pem as a trusted authority in firefox,
>> >however, it still prompts that it is an "Untrusted Connection"
>> >and has the button to add security exception. [which] says "Wrong Site"
>> >and "This iste attempts to identify itself iwth invalid information"
>>
>> Most SSL clients including Firefox, unlike s_client, check that the
>> name in the server cert matches the name of the server they want,
>> almost always as a domain name. The traditional and simple way is
>> the CommonName in the server cert's Subject field is the FQDN.
>> Most clients, I'd expect including Firefox but didn't take time to test,
>> also support (1-level) wildcard, or the SubjectAlternativeName extension
>> which can have multiple domain names or wildcards or some other options
>> that are rarely used. Public CAs often call this "multi-domain", or
>> "Unified Communications" which was Microsoft's jargon for it.
>>
>> If you're doing these certs yourself and can issue whatever you want
>> free anytime, I'd go with simple, but openssl ca (or x509 -req)
>> can do SAN if you set-up the config file(s).
>>
>>
>> ______________________________________________________________________
>> OpenSSL Project                                 http://www.openssl.org
>> User Support Mailing List                    openssl-users@openssl.org
>> Automated List Manager                           majord...@openssl.org
>>
>
>

Reply via email to