[Eisfair_dev] UTF8-Umstellung und openssl - wie erkennen?

[Stephan Manske]

marcus.roeckrath at gmx.de (Marcus Roeckrath) schrieb:
> Stephan Manske wrote:

> > nun, irgendwas muß sich da in Richtung utf8 getan haben, auch in
> > bestehenden Installationen und ohne aktives Umstellen. Sonst hätte
> > openssl nicht das Problem, das es nunmal in meinem Paket hat. Ggf.
> > ist auch nur das Standardverhalten von libssl verändert worden, keine
> > Ahnung.
> 
> Du hast freeradius gegen die Paketversion 2.0.0 der libssl gebaut; schonmal
> probiert, gegen die neueste Paketversion neu zu bauen?

Meinst Du damit, daß ich die radius-binaries mit den neuen Libs
kompilieren soll?

Das Problem betrifft diese Dateien nicht. Ich kann es problemlos
simulieren, indem ich das openssl Kommando aus libssl manuell mit
meinem cnf-Dateien füttere.


> Wenn ich mir die Details von pem-Zertifikaten im Certs-Menu anzeigen lasse,
> die in der issuer- oder subjekt-Zeile Sonderzeichen drinstehen haben,
> scheinen die speziell kodiert zu sein, z. B:
> 
> \xC3\x9C usw.
> 
> Wie sieht das in Deinen ca-Zertifikaten aus?

hab da keine Sonderzeichen


> >> > Jedenfalls ist das das Problem. In meiner openssl.cnf bzw.
> >> > client/ca.cnf ist kein encoding via string_mask vorgeschrieben.
> 
> Meine openssl.cnf sieht da anders aus:
> 
> # This sets a mask for permitted string types. There are several options.
> # default: PrintableString, T61String, BMPString.
> # pkix   : PrintableString, BMPString.
> # utf8only: only UTF8Strings.
> # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
> # MASK:XXXX a literal mask value.
> # WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
> # so use this option with caution!
> 
> string_mask = nombstr
> 
> Ob das immer schon so war, weiß ich nicht, aber in der aktuellen Version des
> Certs-Paketes ist das so.
> 
> Das wäre doch genau Dein Workaround, oder?

in gewisser Weise ja.

Um Mißverständnisse auszuräumen, mit:

> >> > Jedenfalls ist das das Problem. In meiner openssl.cnf bzw.
> >> > client/ca.cnf ist kein encoding via string_mask vorgeschrieben.

meine ich, daß ich keine openssl.cnf bzw nicht die normale auf dem
System benutze sondern selber eine client.cnf und ca.cnf baue, die
mir von Inhalt her von den freeradius vorgegeben wurden.

Und da war halt nie ein string_mask drin (oder ich habe es
versehentlich übersehen, keine Ahnung) jedenfalls hatte ich in
"meinen" cnf das nie drin. Was sich jetzt rächt.


Und es ist halt ein wackliger Workaround, weil er nicht für alle
Fälle hilfreich ist:

alle Paket-Nutzer, die wie ich vor rund einem Jahr ihre CA erzeugt
haben, hilft es weiter. Alles wird wieder funktionieren. Aber alle,
die später erst das Paket benutzt haben oder wie B. die CA jetzt neu
erstellt haben, deren CA ist utf8. Wenn ich denen jetzt ein nombstr
reinhaue, dann fluchen die! Weil dann paßt es für die nicht mehr.

Aus diesem Dilemma suche ich jetzt einen Ausweg. Ich werde wohl
irgendwie in Abhängigkeit vom CA Inhalt diesen Flag auf nombstr oder
eben utf8 setzen müssen. Meine Frage ist: wo / wie mache ich diese
Abfrage am besten?


> >> Wenn das freeradius-Paket nicht mit beliebigen Zeichensatzkodierungen
> >> klarkommt, ist das ein Problem des Paketes, um das sich der Autor kümmern
> >> müsste.
> > 
> > Der Autor bin ich! und ich versuche gerade mich darum zu kümmern. :-/
> 
> Entschuldigung, ich wollte Dir nicht auf die üße treten.

Ich wollte nur sichergehen, daß wir alle wissen, daß genau das hier
gerade versucht wird :)


Ciao, Stephan

-- 
E-Mail: stephan at manske-net.de - WWW: http://stephan.manske-net.de/     //
                                                          PGP 2.6.3i \X/