subjectAltName removed from CSR when signing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

subjectAltName removed from CSR when signing

Greger Lundin
Hi,

I have some firewalls that puts an subjectAltName X509v3 attribute
into the CSR, but when I sign them with my openssl CA, it just throws
that attribute away. VPN clients later requires the subjectAltName to
match the host it connects to, hence it must be present.

I've found many articles how I can add that attribute by using a
custom config file and the -extfile <file> and -extensions <section>
parameters. I've used that as a "work around" to get subjectAltName
into certificates, but it would be better if I could just sign CSRs
and use subjectAltName already specified there.

Are there any security reasons as to why "openssl x509 -req" strips
the attributes or how can I make a custom config file that let's me
use the X509v3 extended attributes exactly as they are in the CSR?

//Greger
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: subjectAltName removed from CSR when signing

Mick-10
On Wednesday 04 Jan 2012 12:33:06 you wrote:
> Hi,
>
> I have some firewalls that puts an subjectAltName X509v3 attribute
> into the CSR, but when I sign them with my openssl CA, it just throws
> that attribute away. VPN clients later requires the subjectAltName to
> match the host it connects to, hence it must be present.

Theoretically at least the VPN client would search the Subject: string for a
Distinguished Name.

If it can't find it there it will look at the subjAltName which as you say is
not always available in a certificate.

> I've found many articles how I can add that attribute by using a
> custom config file and the -extfile <file> and -extensions <section>
> parameters. I've used that as a "work around" to get subjectAltName
> into certificates, but it would be better if I could just sign CSRs
> and use subjectAltName already specified there.

What you can do is set the parameter:

# Extension copying option: use with caution.
copy_extensions = copy

under your CA_default section in your openssl.cnf


> Are there any security reasons as to why "openssl x509 -req" strips
> the attributes or how can I make a custom config file that let's me
> use the X509v3 extended attributes exactly as they are in the CSR?

In the sense that you may not know who's created the CSR or what they've
allowed in it (the whole signing process can be automated), a copy by default
option would seem a bit loose.

However, I better leave the openssl devs or someone more knowledgeable to
comment on this.

--
Regards,
Mick

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: subjectAltName removed from CSR when signing

Dr. Stephen Henson
On Wed, Jan 04, 2012, Mick wrote:

> On Wednesday 04 Jan 2012 12:33:06 you wrote:
>
> > I've found many articles how I can add that attribute by using a
> > custom config file and the -extfile <file> and -extensions <section>
> > parameters. I've used that as a "work around" to get subjectAltName
> > into certificates, but it would be better if I could just sign CSRs
> > and use subjectAltName already specified there.
>
> What you can do is set the parameter:
>
> # Extension copying option: use with caution.
> copy_extensions = copy
>
> under your CA_default section in your openssl.cnf
>

Yes that works, but only for the 'ca' utility.

>
> > Are there any security reasons as to why "openssl x509 -req" strips
> > the attributes or how can I make a custom config file that let's me
> > use the X509v3 extended attributes exactly as they are in the CSR?
>
> In the sense that you may not know who's created the CSR or what they've
> allowed in it (the whole signing process can be automated), a copy by default
> option would seem a bit loose.
>
> However, I better leave the openssl devs or someone more knowledgeable to
> comment on this.
>

Yes that's the reason it isn't enabled by default. If you copy extensions you
should be *really* sure that the extensions are acceptable (e.g. using the
interactive mode of 'ca') because otherwise a CSR could contain (for example)
basicConstraints CA=TRUE and the recipient would get a CA certificate if this
was overlooked.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: subjectAltName removed from CSR when signing

Greger Lundin
In reply to this post by Mick-10
On Wed, Jan 4, 2012 at 1:57 PM, Mick <[hidden email]> wrote:

> On Wednesday 04 Jan 2012 12:33:06 you wrote:
>> Hi,
>>
>> I have some firewalls that puts an subjectAltName X509v3 attribute
>> into the CSR, but when I sign them with my openssl CA, it just throws
>> that attribute away. VPN clients later requires the subjectAltName to
>> match the host it connects to, hence it must be present.
>
> Theoretically at least the VPN client would search the Subject: string for a
> Distinguished Name.
> If it can't find it there it will look at the subjAltName which as you say is
> not always available in a certificate.
Yeah, in theory, but in practise the Android/VPN/Racoon client in this
case requires subjAltName to work...

>> I've found many articles how I can add that attribute by using a
>> custom config file and the -extfile <file> and -extensions <section>
>> parameters. I've used that as a "work around" to get subjectAltName
>> into certificates, but it would be better if I could just sign CSRs
>> and use subjectAltName already specified there.
>
> What you can do is set the parameter:
>
> # Extension copying option: use with caution.
> copy_extensions = copy
> under your CA_default section in your openssl.cnf

Yeah, I found the problem now! I did try before to set that parameter,
but what I didn't get was that "openssl x509 -req" does not read the
openssl.cnf file at all and thusly never saw the copy_extension
parameter. Now that I tried signing the CSR with the "openssl ca"
utility instead, it worked.

I'll try to defend myself (before myself) with that I was colored by
all the lists with "Here's the 10 openssl commands you'll ever need",
which for some reason all seem to recommend "openssl x509 -req"
instead of "openssl ca" for csr signing...

//Greger
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: subjectAltName removed from CSR when signing

Mick-10
On Wednesday 04 Jan 2012 13:40:12 you wrote:

> On Wed, Jan 4, 2012 at 1:57 PM, Mick <[hidden email]> wrote:
> > On Wednesday 04 Jan 2012 12:33:06 you wrote:
> >> Hi,
> >>
> >> I have some firewalls that puts an subjectAltName X509v3 attribute
> >> into the CSR, but when I sign them with my openssl CA, it just throws
> >> that attribute away. VPN clients later requires the subjectAltName to
> >> match the host it connects to, hence it must be present.
> >
> > Theoretically at least the VPN client would search the Subject: string
> > for a Distinguished Name.
> > If it can't find it there it will look at the subjAltName which as you
> > say is not always available in a certificate.
>
> Yeah, in theory, but in practise the Android/VPN/Racoon client in this
> case requires subjAltName to work...
Hmm ... interesting.  Do you know what the client or router expects to find in
there?  I mean, what type of subjAltName string will it work happily with?  

IP:XXX.XXX.X.XX,  DNS:example.com, email:[hidden email]

or even /C=US/L=some_state/O=my_company/CN=VPN_user

I have been having similar problems here with a router which will not return a
DN (or subjAltName) from its certificate to any VPN clients trying to connect
to it.
--
Regards,
Mick

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: subjectAltName removed from CSR when signing

Greger Lundin


Den 4 jan 2012 17:44 skrev "Mick" <[hidden email]>:
>
> On Wednesday 04 Jan 2012 13:40:12 you wrote:
> > On Wed, Jan 4, 2012 at 1:57 PM, Mick <[hidden email]> wrote:
> > > On Wednesday 04 Jan 2012 12:33:06 you wrote:
> > >> Hi,
> > >>
> > >> I have some firewalls that puts an subjectAltName X509v3 attribute
> > >> into the CSR, but when I sign them with my openssl CA, it just throws
> > >> that attribute away. VPN clients later requires the subjectAltName to
> > >> match the host it connects to, hence it must be present.
> > >
> > > Theoretically at least the VPN client would search the Subject: string
> > > for a Distinguished Name.
> > > If it can't find it there it will look at the subjAltName which as you
> > > say is not always available in a certificate.
> >
> > Yeah, in theory, but in practise the Android/VPN/Racoon client in this
> > case requires subjAltName to work...
>
> Hmm ... interesting.  Do you know what the client or router expects to find in
> there?  I mean, what type of subjAltName string will it work happily with?
>
> IP:XXX.XXX.X.XX,  DNS:example.com, [hidden email]
>
> or even /C=US/L=some_state/O=my_company/CN=VPN_user
>
> I have been having similar problems here with a router which will not return a
> DN (or subjAltName) from its certificate to any VPN clients trying to connect
> to it.
> --
> Regards,
> Mick

The Android 2.3 native vpn client uses subjAltName to verify authenticity of the vpn server/gw. I've gotten it to work using DNS:vpngw.example.com, could possibly also work with IP:a.b.c.d . This must correspond to what is specified for "VPN server hostname" in the client.

The VPN server (Juniper/ScreenOS in my case) in turn uses CN (and possibly other attrs) of certificate for user authentication, and the vpn tunnel is tied to a particular CA certificate. Other configs prob possible too.

Greg