> -----Original Message-----
> From: users-admin_at_lists.freeswan.org
> [mailto:users-admin_at_lists.freeswan.org]On Behalf Of Andreas Haumer
> Sent: Mittwoch, 13. März 2002 19:08
> To: George Pop; users_at_lists.freeswan.org; marcus_at_ebootis.de
> Subject: Re: [Users] W2K IPsec tool?
>
>
> Hi!
>
> This is to folloup my mail from today morning and to report
> that I found the solution of this problem. It was quite
> sophisticated...
>
> Executive summary: W2000 certificate management doesn't like
> characters like "+" in the DSN!
>
> Here's the story:
>
> Andreas Haumer wrote:
> >
> > Hi!
> >
> > Thanks for the reply!
> >
> > George Pop wrote:
> > >
> [...]
> >
> > > thing would be to make two freeswans talk together using
> certificates and
> > > after you are sure the config works make the connection from Win2k ..
> >
> > This is what I try to do now.
> > I did setup lots of FreeS/WAN based IPsec tunnels in the
> > past years, and they all work well. So I now how to work
> > with IPsec, though only with PSK configurations so far.
> >
> I had no problem getting two FreeS/WAN VPN gateways
> work together using my x509 certificates. It was a
> matter of 3 minutes to set this up, because I already
> had one side (including all the certificates) set up.
>
> > With Linux & FreeS/WAN I have logfiles and tools like
> > strace and tcpdump to debug in case something is not working.
> > But on this damned W2K box I have nothing. This drives me crazy... :-(
> >
> Marcus Müller wrote me how to change the windows registry
> in order to get useful log information out of it.
> Thanks, Marcus! That did help a lot!
>
> If someone is interested, here's how to get Windows log
> this information:
>
> Add the following registry entry (on my system I didn't have this):
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley
>
> And here, add the a REG_DWORD entry named EnableLogging
> and set it's value to "1"
>
> (ah, isn't that intuitive and user-friendly? I really
> like Windows, it makes an administrator's life so full
> of joy and fun. But I wonder how it comes Microsoft
> calls a fully commented configuration file in /etc
> complicated???)
>
> Anyway, after a reboot (!) W2K creates a logfile called
> %SystemRoot%\debug\Oakley.log
>
> Here I found a first hint: Windows complained something with
> the following messages:
>
> [...]
> error in CertStrToName = -2146885597
> Failed to get issuer DN
> [...]
>
> I was then looking at my W2000 ipsec.conf file and
> noticed the syntax of my root CA ID. As my company
> is called "xS+S", I used the following DSN:
>
> C=AT, S=Austria, L=Vienna, O=xS+S, CN=xS+S CA
>
> In a wild guess, I changed my Root CA and all other certificates
> to have names without special characters like "+", so I now
> have a root CA DSN like
>
> C=AT, S=Austria, L=Vienna, O=xss, CN=xss CA
>
> and now it works!!!
> The IPsec tunnel now goes up in the second I transmit the
> first packet from the W2K computer to the network behind
> my FreeS/WAN gateway.
>
> But remember, with two FreeS/WAN gateways I didn't have a
> single problem with my original certificates including
> the "xS+S" DSN! Very strange.
>
> Is there a RFC which specifies the legal characters in
> a DSN or is this "feature" a "Microsoftism"?
you have touched a very sensitive subject where no clear-cut
solutions exist - namely the coding of distinguished names
containing special characters. E.g. the IETF PKIX RFC 2459
"Internet X.509 Public Key Infrastructure Certificate and CRL Profile"
defines the distinguished name to consist of the types
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1.. MAX)),
bmpString BMPString (SIZE (1..MAX)) }
The Name describes a hierarchical name composed of attributes, such
as country name, and corresponding values, such as US. The type of
the component AttributeValue is determined by the AttributeType; in
general it will be a DirectoryString.
The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString. The
UTF8String encoding is the preferred encoding, and all certificates
issued after December 31, 2003 MUST use the UTF8String encoding of
DirectoryString (except as noted below). Until that date, conforming
CAs MUST choose from the following options when creating a
distinguished name, including their own:
(a) if the character set is sufficient, the string MAY be
represented as a PrintableString;
(b) failing (a), if the BMPString character set is sufficient the
string MAY be represented as a BMPString; and
(c) failing (a) and (b), the string MUST be represented as a
UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
to represent the string as a UTF8String.
Exceptions to the December 31, 2003 UTF8 encoding requirements are as
follows:
(a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer and and the old
name encoding as subject, or vice-versa.
(b) As stated in section 4.1.2.6, the subject field MUST be
populated with a non-empty distinguished name matching the
contents of the issuer field in all certificates issued by the
subject CA regardless of encoding.
The TeletexString and UniversalString are included for backward
compatibility, and should not be used for certificates for new
subjects. However, these types may be used in certificates where the
name was previously established. Certificate users SHOULD be
prepared to receive certificates with these types.
In addition, many legacy implementations support names encoded in the
ISO 8859-1 character set (Latin1String) but tag them as
TeletexString. The Latin1String includes characters used in Western
European countries which are not part of the TeletexString charcter
set. Implementations that process TeletexString SHOULD be prepared
to handle the entire ISO 8859-1 character set.[ISO 8859-1]
As you can see from this gibberish, Microsoft cannot be blamed when
they have problems with the coding of special characters. The
X.509 patch currently codes strings containing special characters
as T61Strings whereas the latest version 1.3 of SSH Sentinel seems
to code them as UTF8Strings.
As a general guideline I just can recommend to refrain from using
special characters such as "umlauts", '+' or '&', and even '@' lately
seems to pose some problems. I intend to make comparisons of
such strings more tolerant in future versions of the X.509 patch,
but there will always remain a certain risk that the two endpoints
of an IPsec connection using distinguished names will have different
opinions concerning the comparison of these IDs.
>
> Anyway, this seems to be the solution for a strange problem.
> Thanks to all who responded to my request for help.
> Special thanks goes to Marcus Müller, for his hint with
> the registry, and of course for his W2K ipsec tool!
>
> - andreas
>
> --
> Andreas Haumer | mailto:andreas_at_xss.co.at
> *x Software + Systeme | http://www.xss.co.at/
> Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0
> A-1100 Vienna, Austria | Fax: +43-1-6060114-71
Regards
Andreas
======================================================================
Andreas Steffen e-mail: andreas.steffen_at_zhwin.ch
Zuercher Hochschule Winterthur home: http://www.zhwin.ch/~sna/
CH-8401 Winterthur (Switzerland) phone: +41 76 340 25 56
===============================================================[ZHW]==
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:42 CEST