Dies ist eine alte Version des Dokuments!
Übersicht veralteter Radsecproxy-Konfigurationen
Auf dieser Seite haben wir eine Übersicht von ehemaligen radsecproxy-Konfigurationen zusammengestellt, die inzwischen veraltet sind. Sollte sich bei Ihnen noch eine solche Konfiguration finden, ersetzen Sie sie bitte.
Zu allen Konfigurationen ist ein Grund angegeben, weshalb die Konfiguration ersetzt werden sollte und welche Auswirkungen die Ersetzung ggf. hat.
MatchCertificateAttribute und CertificateNameCheck
Alte Konfiguration, gilt für client und server
server tld1.eduroam.de {
Host <ip-addr>
Type tls
CertificateNameCheck Off
MatchCertificateAttribute CN:/^tld1\.eduroam\.de$/
[...]
}
Alternativ auch:
server tld1.eduroam.de {
Host <ip-addr>
Type tls
CertificateNameCheck Off
MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
[...]
}
Neue Konfiguration
server tld1.eduroam.de {
Host <ip-addr>
Type tls
ServerName tld1.eduroam.de
[...]
}
Alternativ:
server tld1.eduroam.de {
Type tls
StatusServer On
}
client tld1.eduroam.de {
Type tls
}
Hingergrund
Bis radsecproxy 1.9 hat radsecproxy immer auf die konfigurierte Host Information zurückgegriffen, in diesem Fall also auf die IP-Adresse.
Um dieses Verhalten abzuschalten musste CertificateNameCheck Off gesetzt und die Namensüberprüfung des Zertifikats manuell konfiguriert werden.
Seit radsecproxy 1.10 gibt es die Konfigurations-Option ServerName, die das Verhalten anpasst. Statt der Host-Konfiguration wird für die Namensüberprüfung die Konfiguration unter ServerName genutzt.
Das hat zusätzlich den Vorteil, dass hier die OpenSSL-interne Überprüfung genutzt werden kann, die automatisch SubjectAltName:DNS prüft, und nur wenn das nicht vorhanden ist auf den CommonName(CN) zurückgreift, der inzwischen als deprecated gilt.
Zukünftige radsecproxy-Versionen werden ggf. dann die CN-Überprüfung vollständig weglassen.
Wenn die Host Konfiguration nicht vorhanden ist, sondern der Servern schon als tld1.eduroam.de (bzw. tld2…/tld3…) benannt ist, kann die ServerName Konfiguration auch komplett weggelassen werden, da radsecproxy hier direkt den richtigen Namen zur Überprüfung nutzt.
Matching nur auf tld1.eduroam.de
Alte Konfiguration, gilt für client und server
server tld1.eduroam.de {
[...]
MatchCertificateAttribute CN:/^tld1\.eduroam\.de$/
[...]
}
server tld2.eduroam.de {
[...]
MatchCertificateAttribute CN:/^tld1\.eduroam\.de$/
[...]
}
server tld3.eduroam.de {
[...]
MatchCertificateAttribute CN:/^tld1\.eduroam\.de$/
}
Neue Konfiguration
server tld1.eduroam.de {
[...]
ServerName tld1.eduroam.de
[...]
}
server tld2.eduroam.de {
[...]
ServerName tld2.eduroam.de
[...]
}
server tld3.eduroam.de {
[...]
ServerName tld3.eduroam.de
[...]
}
Alternativ, falls radsecproxy < 1.10 eingesetzt wird
# NUR FÜR RADSECPROXY 1.9 ODER FRÜHER
server tld1.eduroam.de {
[...]
MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
[...]
}
server tld2.eduroam.de {
[...]
MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
[...]
}
server tld3.eduroam.de {
[...]
MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
[...]
}
Hingergrund
Historisch hatten die drei tld-Server jeweils eigene Zertifikate. Im Zuge einer Umstellung wurde das auf ein gemeinsames Zertifikat mit verschiedenen SubjectAltNames ersetzt. Daher kann es sein, dass in der Konfiguration einfach nur der Haupt-Name des Zertifikats (tld1.eduroam.de) als Matching eingetragen wurde.
Perspektivisch sollen die Server aber wieder individuelle Zertifikate erhalten, d.h. es ist wichtig, dass der Namens-Check auf den Namen des Servers prüft.
Bei radsecproxy-Versionen bis 1.9 ist die Option ServerName noch nicht vorhanden, d.h. hier muss über MatchCertificateAttribute gearbeitet werden.
Alte IP-Adresse für tld3
Alte Konfiguration, gilt für client und server
server tld3.eduroam.de {
Host 194.95.245.98
[...]
}
Neue Konfiguration
server tld3.eduroam.de {
Host 193.174.75.142
[...]
}
Hingergrund
Im Zuge einer Umstellung hat sich die IP-Adresse von tld3 geändert.
Kein Eintrag für tld3
Alte Konfiguration, gilt für client und server
server tld1.eduroam.de {
[...]
}
server tld2.eduroam.de {
[...]
}
client tld1.eduroam.de {
[...]
}
client tld2.eduroam.de {
[...]
}
realm * {
server tld1.eduroam.de
server tld2.eduroam.de
}
Neue Konfiguration
server tld1.eduroam.de {
[...]
}
server tld2.eduroam.de {
[...]
}
server tld3.eduroam.de {
[...]
}
client tld1.eduroam.de {
[...]
}
client tld2.eduroam.de {
[...]
}
client tld3.eduroam.de {
[...]
}
realm * {
server tld1.eduroam.de
server tld2.eduroam.de
server tld3.eduroam.de
}
Hingergrund
Der dritte Föderations-Server tld3.eduroam.de wurde 2021 hinzugefügt. Ältere Konfigurationen haben den Server ggf. nicht eingetragen.