[general]
…
tlscapath=/etc/ssl/certs/ ; see http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl
;tlsdontverifyserver=yes ;
…
register => DUStel?tls://[email protected]/malcolm ; inbound, callback-extension: malcolm
[DUStel] ; outbound, see parameter transport
type=peer ; default is peer; if not specified = warning on CLI
host=secure.dus.net ; IP of proxy.dus.net = secure.dus.net = sips.dus.net
fromdomain=secure.dus.net ; optional, to hide your local domain
fromuser=000387xxxxxx ; required, to hide your local user, otherwise sometimes IP blocked by fail2ban
auth=000387xxxxxx:[email protected] ; realm must match: dus.net
transport=tls ; secure signalling (TLS): forced
encryption=yes ; media encryption (SDES-sRTP): forced
…
[default]
exten => malcolm,1,Dial(100)
RapidSSL ist keine wohl-bekannte CA – die braucht immer sein Intermediate zu GeoTrust und optional zu Equifax. Außerdem ist das ein Wildcard-Zertifikat auf *.dus.net, was Asterisk und PJSIP ablehnen. Aber hat sich erledigt: dus.net verwendet wieder das Zertifikat von letzter Woche (COMODO/AddTrust).Die CA-Certs stellt doch die distribution bereit oder?
Mein Asterisk hat bei eingehenden Anrufen nach dem Kontext „dus.net“ gesucht. Weil ich den nirgends hatte, konnte Asterisk das nicht zuordnen. Ein Lösung wäre insecure=invite gewesen. Stattdessen habe ich die Zeile auth eingefügt und konnte mir so insecure=invite ersparen. Würde dus.net als Realm den registerten Host benutzen – secure.dus.net, so wie das 1&1 macht – hätten wir den Schlamassel nicht.Was meinst Du mit realm-mismatch?