[Openswan dev] ID_DER_ASN1_DN change in 2.5.17, was Re: [Openswan Users] Openswan on Fedora 9
Michael H. Warfield
mhw at WittsEnd.com
Mon Jun 9 13:04:06 EDT 2008
On Mon, 2008-06-09 at 12:11 -0400, Paul Wouters wrote:
>
> > > > My problem is in X.509 cert handling. The problem looks like it's not
> > > > handling cert DNs as the Main ID.
> There is a new setting, which I did not know about:
>
> leftid=%fromcert
Yeah, I just dropped that into my default section in place of the
leftid="{Cert subject}" and that works like a charm.
The other thing I had run into with 2.6.09 and 2.6.13 was that even
with the subject corrected using the precise subject in the leftid, it
wasn't finishing negotiation and the connections were unusable. That
seems to be fixed in 2.6.14 and I'm once again able to ping across the
tunnel.
> I'm strongly leaning towards undoing the code that causes this to be
> neccessary, unless someone can convince me that the default when
> using leftcert= should be ID_IPV4_ADDR instead of ID_DER_ASN1_DN. I
> can come up with no valid reason for this.
> The comment with that commit says:
> commit f789468cee4e8d68645eae87d0a016edba575e45
> Author: Michael Richardson <mcr at xelerance.com>
> Date: Tue Dec 18 19:53:35 2007 -0500
> permit leftid= to be used even when using leftcert. Do not override
> the ID type unless the ID type is none, or %fromcert.
> So it looks like specifying leftid="something" was ignored when leftcert=
> was used. However, the fix for this caused a side effect changing the
> *default* type of id when leftcert= is used from ID_DER_ASN1_DN to
> ID_IPV4_ADDR. This will cause major headaches for people upgrading from
> openswan 2.4.x
Yeah, that's a major PITA. I don't know about totally undoing the
code, but the default when certs are used should be ID_DER_ASN1_DN to be
consistent with current usage at the very least.
At least I now know what to set the default to in all my default
sections on all my systems to get back to the previous behavior.
Thanks!
> > I do see a couple of syslog messages that say to report this:
> >
> > Jun 9 11:41:14 kolvir pluto[1240]: "remus" #2: alloc_bytes1() was mistakenly asked to malloc 0 bytes for st_skey_ar in duplicate_state, please report to dev at openswan.org
>
> Thanks. We now know where this is done, and will see about avoiding these in the future.
>
> > Seems to be working, though. Continuing to test.
>
> Let us know how things progres.
>
> Paul
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://lists.openswan.org/pipermail/dev/attachments/20080609/0228691b/attachment.bin
More information about the Dev
mailing list