[GEKLÄRT] Snom findet eigenen Registrar nicht / DNS Probleme

[-KeX-]

Hallo

Die frage wurde in diesem Thread schon mal gestellt und auch geklärt. Ich hätte das auch so versucht, allerdings habe ich keine Ahnung warum das bei mir so nicht geht.

Ich hab auf meinem Testserver Openser mit TLS installiert. Das ding heist testcenter. Am DNS sind folgende Einträge dafür:

@                  IN      NAPTR 100 100 "s" "SIP+D2U" "" _sip._udp.mydomain.com.
@                  IN      NAPTR 110 100 "s" "SIP+D2T" "" _sip._tcp.mydomain.com.
@                  IN      NAPTR 120 100 "s" "SIPS+D2T" "" _sips._tcp.mydomain.com.

_sip._udp       IN      SRV   100 100 5060 sip1.mydomain.com.
_sip._tcp        IN      SRV   100 100 5060 testcenter
_sips._tcp      IN      SRV   100 100 5061 testcenter

testcenter      IN      A       192.168.0.156

Wenn ich jedoch am snome als registrar testcenter (auch testcenter.mydomain.com probiert) eingeb, findet er nie den Server.

Im DNS cache vom phone scheinen alle einträge auf, auch die IP. In der Systeminfo scheint aber immer Not Found auf : /

Ich weiss nicht warum der den nicht findet. Hab ich noch irgendwo einen Fehler drinnen?

Wär super, wenn mir da wer helfen könnt.

chris...

 

[snomy]

Bitte die NAPTR records erstmal weglassen:

_sip._udp       IN      SRV   100 100 5060 sip1
_sip._tcp        IN      SRV   100 100 5060 testcenter
_sips._tcp      IN      SRV   100 100 5061 testcenter

testcenter      IN      A       192.168.0.156
sip1             IN      A       w.x.y.z

Geht es so besser ? Wenn nicht, dann bitte einen kurzen ethereal Trace eines Telefonstarts mit dieser Registrierung mitschneiden und gezipped an [email protected] senden.

 

[-KeX-]

Hallo snomy,

Danke für deinen Hinweis, allerdings hat mir das nichts geholfen : ) Allerdings weiss ich jetzt wie's geht:
Der SRV Eintrag im DNS muss so aussehen:

_sips._tcp      IN      SRV   0 0 5061 testcenter

Dann funktionierts. Andernfalls, liefert der (mein) DNS Server immer ein 'Not found' zurück. Mit 0 0 anstatt 100 100 liefert er das auch zurück. Versteh ich zwar nicht ganz, aber so gehts. Mit und ohne NAPTR

Eine alternative ist noch, dass man beim registrar und outbound proxy

testcenter:5061;transport=tls

angibt. Dann wird der DNS Record nicht gebracht.

Am openSER musste ich noch zusätzlich UDP Port 5060 öffnen, damit die Registrierung der Phones hinhaut. Mit diesem offenen Port wird zwar nichts im Klartext übertragen, auch keine Verbindungen auf diesen, ohne den Port krieg ich aber immer ein:

500 I'm terribly sorry, server error occurred (7/TM)

Weiss ich auch nicht warum, aber da mach ich mich noch schlau.

Das sind meine Erfahrungen. Vielleicht helfens wem. Wenn wer meine Unklarheiten versteht, kann er sich gerne bei mir melden. thx

chris...

 

[fhl.s02313]

Hallo,

für meine Diplomarbeit installiere ich z.Z. ebenfalls einen OpenSER mit TLS-Unterstützung. Die angeschlossenen Clients (Snom 200 und Snom 360) sollen mittels TLS kommunizieren. In meiner Testumgebung (kein DHCP und DNS) funktioniert die Verbindung ohne TLS bereits. Nur mit TLS gibt es noch Probleme. Geht es ohne den DNS-Eintrag für SIPS nicht?

Eine alternative ist noch, dass man beim registrar und outbound proxy

testcenter:5061;transport=tls

angibt. Dann wird der DNS Record nicht gebracht.

Klappt dieser Hinweis nur für die Snoms?

Am openSER musste ich noch zusätzlich UDP Port 5060 öffnen, damit die Registrierung der Phones hinhaut. Mit diesem offenen Port wird zwar nichts im Klartext übertragen, auch keine Verbindungen auf diesen, ohne den Port krieg ich aber immer ein:

500 I'm terribly sorry, server error occurred (7/TM)

Weiss ich auch nicht warum, aber da mach ich mich noch schlau.

Hast du schon die Ursache dafür herausgefunden?

Danke schonmal, falls du dir die Zeit zum antworten nimmst.

Torsten

 

[-KeX-]

Hallo Torsten,

Der Fehler kommt anscheinend daher, dass der SIP RFC das Protokoll UDP vorschlägt, also ohne diesem gehts nicht. Allerdings könnte es sein, dass in der openser.cfg etwas drinnen is, das den UDP Port benötigt. Sobald du den UDP Port öffnest, is der Fehler weck.

Das mit dem xx.xx.xx.xx:5061;transport=tls funktioniert nur bei Snom. Dann brauchst du auch keinen DNS. Schau mit Ethereal mit, was u. wohin das Telefon was schickt. Siehst eh gleich im REGISTER Request, da steht im VIA was als Transportprotokoll verwendet wird:

Via: SIP/2.0/TLS .....

Bei Minisip gibst einfach in der .minisip.cfg an:

<proxy_port>
5061
</proxy_port>
<transport>
TLS
</transport>

Musst hald dann noch sagen, dass ein TLS Server is.

Über was genau schreibst du deine Diplomarbeit (DA). Würd mich interessieren, da ich auch gerade an meiner DA schreib : ) Und was verwendes du zum testen deines TLS enabled SER?

chris...

 

[fhl.s02313]

N'Abend,

danke erstmal für die Antworten. Vielleicht integriere ich dann doch noch einen DNS-Server, damit habe ich ja eigentlich alle Clients erschlagen.

Über was genau schreibst du deine Diplomarbeit (DA). Würd mich interessieren, da ich auch gerade an meiner DA schreib : ) Und was verwendes du zum testen deines TLS enabled SER?

Ich untersuche VoIP-Clients hinsichtlich ihrer Sicherheitsmerkmale und entsprechende serverseitige Konfigurationen; vorallem hinsichtlich dem Einsatz von Zertifikaten. Den praktischen Teil habe ich aber erst vor kurzem begonnen und bin da noch stark am rumbasteln.
Als TLS-Endgeräte habe z.Z. nur Snom 360, das GXP-2000 von Grandstream müßte aber bald kommen. Softphones, die ich bis jetzt gefunden habe, können leider kein TLS / SRTP, bis auf MiniSIP. Kennst du vielleicht noch weitere Soft- und Hardphones?

Tschau
Torsten

 

[-KeX-]

Hallo,

Das GXP-2000 kann SIPS und/oder SRTP?? Echt? Da muss ich mal schaun, hab so ein auch rumstehen, aber von dem weiss ich noch nix.

Ich verwende minisip, ein Snom 190 u. das softSnom (Snom 360). Weiters soll noch SIPP tls können (zum testen von sips). Vom X-Lite hab ich jetzt auch etwas gelesen, dass das TLS können sollte, hab ich aber noch nicht versucht.

Verwendest du nur Serverseitige Zertifikate? Oder auch Clientseitige?
chris...

 

[fhl.s02313]

Das GXP-2000 kann SIPS und/oder SRTP?? Echt? Da muss ich mal schaun, hab so ein auch rumstehen, aber von dem weiss ich noch nix.

Da muß ich mich wohl entschuldigen. Die Geräte werden mir gestellt und da ich das Grandstream noch nicht habe, habe ich mich damit noch nicht befaßt. Habe mir eben das Datenblatt angeschaut. Anscheinend kann es kein TLS / SRTP. Komisch ist aber, daß es immer wieder im Zusammenhang mit verschlüsselter Kommunikation genannt wird; z.B. "sipgate-Crypto" von Sipgate.de. Vielleicht ist da aber auch eine spezielle Firmware drauf.

Verwendest du nur Serverseitige Zertifikate? Oder auch Clientseitige?

Ziel ist es, daß beide sich authentifizieren. Davon bin ich aber noch ein Stückchen entfernt. Kann das Snom 360 überhaupt Zertifikate aufnehmen? Im Web-Interface kann man zwar irgendwelche Zertifikate hochladen, jedoch sollen diese nur für den internen Webserver sein.
Aber erstmal muß TLS serverseitig funktionieren - Schritt für Schritt
Werde die Tipps aus dem ursprünglichen Beitrag morgen erstmal testen.

Dann erstmal Gute Nacht
Torsten

 

[-KeX-]

k, dachte schon ich hab da was verpasst : ) Aber Grandstream bietet ja nicht soooo viel .... Funktionsumfang bei Ihren Geräten : / Werd morgen mal wegen dem Crypto Zeugs schaun.

Du kannst beim Snom an zwei Stellen Zertifikate hochladen.Eines ist für den Webserver (https) wie du schon gesagt hast, das andere ist für TLS. Allerdings weiss ich jezt nicht ob das nur ein Zertifikat einer CA ist od. eins für Clientseitige Authentifizierung. Vielleicht kann das ein snom spezialist beantworten??

Wenn du TLS am laufen hast, ists von der Serverseitigen zur Clientseitigen Authentifizierung nicht mehr weit. 1 Parameter in der openser.cfg ändern : ) (minisp kann client auth auch)

So, ich geh auch mal ins Bett.
chris...

 

[fhl.s02313]

Hallo,

habe heute wegen dem Grandstream rungesucht. In der aktuellen Version kann es noch kein TLS / SRTP. In einer der nächsten Firmwareversionen soll aber enthalten sein, daher wird es auch immer in Pressemitteilungen usw. genannt.

Die beiden Zertifikate, die man beim SNOM hochladen kann sind zum einem das Zertifikat für den Webserver, das zweite ist das Root-Zertifikat. Also ist mit dem Snom keine Client-Authentifizierung möglich.

Nun zu meinem OpenSER
Also der Tip mit

[IP-Adresse]:5061;transport=tls

klappt. Jedenfalls versucht schickt das Snom SIP-Nachrichten über TLS heraus. Jedoch antwortet der Server nicht
Hier mal den Teil für TLS aus meiner openser.cfg. Eigentlich so erstellt, wie es in der Anleitung steht. Muß in dem Routingabschnitt noch was eingetragen werden für TLS?

debug=3            # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no    # (cmd line: -E)

/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/

check_via=no    # (cmd. line: -v)
dns=no          # (cmd. line: -r)
rev_dns=no      # (cmd. line: -R)
#port=5060
children=4
#fifo="/tmp/openser_fifo"

#
# uncomment the following lines for TLS support
disable_tls = 0 
listen = tls:141.xxx.xxx.xxx:5061   
listen = tcp:141.xxx.xxx.xxx:5060
listen = udp:141.xxx.xxx.xxx:5060
#tls_port_no = 5061   
tls_verify = 0 
tls_require_certificate = 0
tls_method = SSLv23  
tls_certificate = "//etc/openser/tls/openser/openser-cert.pem"
tls_private_key = "//etc/openser/tls/openser/openser-privkey.pem"
tls_ca_list = "//etc/openser/tls/openser/openser-calist.pem"

Nach dem Start hört OpenSER auf folgende Ports:

Listening on
             udp: 141.xxx.xxx.xxx [141.xxx.xxx.xxx]:5060
             tcp: 141.xxx.xxx.xxx [141.xxx.xxx.xxx]:5060
             tls: 141.xxx.xxx.xxx [141.xxx.xxx.xxx]:5061
Aliases:
             tls: openser.localdomain:5061
             tls: openser:5061
             tcp: openser.localdomain:5060
             tcp: openser:5060
             udp: openser.localdomain:5060
             udp: openser:5060

Hört also auch auf 5060, wie du es vorher beschrieben hast.

Seltsam alles

Torsten

 

[-KeX-]

Hallo Torsten,

Starte openSER im debugmodus:

/usr/local/sbin/openser -dddddddddddddddddddddddddddd -P /var/run/openser.pid

And try to reconnect our phone. You should see what the phone/server are talking. *ups hier kann ich ja auch deutsch schreibn : )
Oder schau mit ssldump mit, was die beiden Miteinander im Verbindungsaufbau austauschen:

ssldump -HAa

Wenn auf dem Server sonst viel läuft, is das besser:

ssldump -HAa port 5061

openserctl moni

wirst du eh kennen? Zum überwachen vom SER.

chris...

 

[fhl.s02313]

N'Abend wieder

also ssldump habe ich noch nicht gekannt; feine Sache, denn nun weiß ich was der Fehler (hoffentlich) ist. Folgendes wurde während des Verbindungsaufbaus von MiniSIP zum Server ausgegeben:

3 1  0.0012 (0.0012)  C>S SSLv2 compatible client hello
  Version 3.1
  cipher suites
  Unknown value 0x39
  Unknown value 0x38
  Unknown value 0x35
  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  TLS_RSA_WITH_3DES_EDE_CBC_SHA
  SSL2_CK_3DES
  Unknown value 0x33
  Unknown value 0x32
  Unknown value 0x2f
  SSL2_CK_RC2
  TLS_DHE_DSS_WITH_RC4_128_SHA
  TLS_RSA_WITH_RC4_128_SHA
  TLS_RSA_WITH_RC4_128_MD5
  SSL2_CK_RC4
  SSL2_CK_RC464
  TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
  TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
  TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
  TLS_DHE_RSA_WITH_DES_CBC_SHA
  TLS_DHE_DSS_WITH_DES_CBC_SHA
  TLS_RSA_WITH_DES_CBC_SHA
  SSL2_CK_DES
  TLS_DHE_DSS_WITH_RC2_56_CBC_SHA
  TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
  TLS_RSA_EXPORT1024_WITH_RC4_56_MD5
  TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
  TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
  TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
  TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
  SSL2_CK_RC2_EXPORT40
  TLS_RSA_EXPORT_WITH_RC4_40_MD5
  SSL2_CK_RC4_EXPORT40
3 2  0.0017 (0.0004)  S>CV3.1(74)  Handshake
      ServerHello
        Version 3.1
        random[32]=
          44 29 7d c6 f5 9e 87 e5 ee 0e c4 9c 35 d1 98 bb
          c7 a8 47 a7 a3 dc 0a bd 4b aa 8e 3f 26 e8 f5 e4
        session_id[32]=
          a9 2e 64 48 b2 b3 e4 94 59 15 30 a5 a2 4a 64 bb
          32 00 38 7a 61 2a 80 f6 68 34 f3 59 65 aa d2 5d
        cipherSuite         Unknown value 0x35
        compressionMethod                   NULL
3 3  0.0018 (0.0000)  S>CV3.1(1624)  Handshake
      Certificate
3 4  0.0018 (0.0000)  S>CV3.1(4)  Handshake
      ServerHelloDone
3 5  0.0067 (0.0049)  C>SV3.1(2)  Alert
    level           fatal
    value           unknown_ca
3    0.0073 (0.0006)  S>C  TCP FIN
3    0.0080 (0.0006)  C>S  TCP RST

Aus der vorvorletzten Zeile schließe ich, daß das Zertifikat des Servers nicht (erfolgreich) gegen eine CA geprüft werden konnte und somit der SSL-Handshake abgebrochen wurde.

Zum erstellen der Zertifikate habe ich die mitgelieferten Skripte "gen_rootCA.sh" und "gen_usercert.sh" verwendet. Die Ergebnisse von "gen_usercert.sh" sind die Serverzertifikate für OpenSER; habe sie somit in die "openser.cfg" eingetragen. Das Ergebnis von "gen_rootCA.sh" ist u.a. das Rootzertifikat der CA (./rootCA/cacert.pem), welches man in MiniSIP oder den SNOMs läd.
Ist mein Verständnis soweit korrekt?

Tschau
Torsten

 

[-KeX-]

Morning,

Das Problem hatte ich auch. Das is ganz was einfaches : )

<ca_file>
        /home/chris/DA/tcs_ca-cacert.pem
</ca_file>

Füg das zu deiner .minisip.conf hinzu. Dann funktioniert das.

ssldump is super, denn da siehst du auch was Server/Client hin und her schicken. Ethereal kennt leider kein sip-tls bzw. sips drum siehst da nicht was hin und hergeschickt wird.

Hoff ich konnt dir helfen. Dafür will ich auch in deiner DA erwähnt werden ; )

chris...

 

[fhl.s02313]

Hallo,

das mit dem Zertifikat in MiniSIP hatte ich schon, nur irgendwie wollte er das nicht. Habe heute neue erstellt und nun kann sich MiniSIP per TLS am OpenSER anmelden

Als nächstes habe ich mich an die Snoms rangemacht. Ohne TLS klappt alles, nur mit TLS stürzen meine beiden Geräte (Snom 360) immer ab, nachdem sie das Serverzertifikat erhalten haben.

openser:~# ssldump -HAa port 5061
New TCP connection #1: [client](2049) <-> [openser](5061)
1 1  0.2966 (0.2966)  C>SV3.1(63)  Handshake
      ClientHello
        Version 3.1
        random[32]=
          3c 26 70 09 77 eb d3 55 38 c0 69 4b a5 df d1 d3
          8c 06 e6 27 c7 b0 6b a6 c2 d0 2f 83 ad 09 52 23
        cipher suites
        TLS_RSA_WITH_RC4_128_MD5
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_NULL_MD5
        TLS_RSA_WITH_NULL_SHA
        TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
        TLS_DH_anon_WITH_RC4_128_MD5
        TLS_RSA_WITH_DES_CBC_SHA
        TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
        TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
        TLS_DH_anon_WITH_DES_CBC_SHA
        compression methods
                  NULL
1 2  0.2973 (0.0007)  S>CV3.1(74)  Handshake
      ServerHello
        Version 3.1
        random[32]=
          44 2a 5e 06 77 ad 34 c8 82 03 66 38 6d 08 1c c9
          7d d8 23 e5 05 c1 1b a8 04 9b 2b 0c 5e d8 36 d8
        session_id[32]=
          de dc 9b bf 7b 6c b3 3e 72 1d 88 df 22 15 f1 ae
          d1 92 6d c3 42 25 cf 67 93 40 73 60 fa 49 ae 39
        cipherSuite         TLS_RSA_WITH_RC4_128_SHA
        compressionMethod                   NULL
1 3  0.2974 (0.0000)  S>CV3.1(1689)  Handshake
      Certificate
1 4  0.2974 (0.0000)  S>CV3.1(4)  Handshake
      ServerHelloDone
1    131.2767 (130.9793)  S>C  TCP FIN
1    131.2781 (0.0013)  C>S  TCP FIN
#########
Dann ist Schluß und das Telefon hat sich aufgehangen. Nur Netzstecker raus & rein hilft.

Ist dies bei dir auch der Fall? Denke es liegt daran, daß denen das Zertifikat der Root-CA fehlt; nur wo hochladen?
Als Proxy habe ich "[server.domain]:5061;transport=tls" angegeben, da ich keinen Zugriff auf den DNS habe.

Hoff ich konnt dir helfen. Dafür will ich auch in deiner DA erwähnt werden ; )

Wofür ist sonst die Quellenangabe da

Torsten

 

[-KeX-]

Hallo,

Ich hab zwar kein Snom 360 sondern ein snomSoft, das is aber die selbe Software Version. Also müssts in etwa gleich sein.

Bei mir siehts so aus:

New TCP connection #1: C(1497) <-> S(5061)
1 1  0.0597 (0.0597)  C>S  Handshake
      ClientHello
        Version 3.1
        cipher suites
        TLS_RSA_WITH_RC4_128_MD5
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_NULL_MD5
        TLS_RSA_WITH_NULL_SHA
        TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
        TLS_DH_anon_WITH_RC4_128_MD5
        TLS_RSA_WITH_DES_CBC_SHA
        TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
        TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
        TLS_DH_anon_WITH_DES_CBC_SHA
        compression methods
                  NULL
1 2  0.0604 (0.0007)  S>C  Handshake
      ServerHello
        Version 3.1
        session_id[32]=
          8f b0 1e 3e 52 e4 da 32 99 66 c9 62 4b 7c e1 ff
          53 67 00 41 11 ea 1f c9 eb 58 8d 59 ae 50 1a 94
        cipherSuite         TLS_RSA_WITH_RC4_128_SHA
        compressionMethod                   NULL
1 3  0.1375 (0.0771)  S>C  Handshake
      Certificate
1 4  0.1375 (0.0000)  S>C  Handshake
      ServerHelloDone
1 5  0.4497 (0.3121)  C>S  Handshake
      ClientKeyExchange
1 6  0.4497 (0.0000)  C>S  ChangeCipherSpec
1 7  0.4497 (0.0000)  C>S  Handshake
1 8  0.4548 (0.0050)  S>C  ChangeCipherSpec
1 9  0.4548 (0.0000)  S>C  Handshake
1 10 0.5904 (0.1355)  C>S  application_data
1 11 0.5909 (0.0005)  S>C  application_data
1 12 0.8415 (0.2505)  C>S  application_data
1 13 0.8424 (0.0009)  S>C  application_data

Dann steht di Verbindung. Bei dir Trennt der Server die Verbindung nach 130 Sec. Das passiert bei mir, auch, aber erst nach dem Login. Die TLS Verbindung wird nach inaktivität (Timeout) geschlossen.

1 14 131.8223 (130.9798)  S>C  Alert
1    131.8224 (0.0000)  S>C  TCP FIN

Ich glaub bei dir liegts am Zertifikat. Das Zertifikat is zu gross (zu viele Bit) für das Snom. Probier das mal:

openssl s_client -connect ServerIP:5061 -debug

Da kommt dann ganz viel Zeugs (normaler SSL/TLS Verbindungsaufbau), unter anderem auch das Zertifikat und der public Key des Servers. Mein Key liefert folgendes:

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: Da steht die aktuelle Session-ID
    Session-ID-ctx:
    Master-Key:Und hier der Master-Key den ich nicht poste ; )
    Key-Arg   : None
    Start Time: 1143663302
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

Glaube du hast ein 2048 bit Zertifikat und Snom kommt damit nicht zurecht (glaub das hab ich gelesen). Vielleicht liegts an dem?

Hoffe es hilft?

chris...

 

[fhl.s02313]

Geschafft

Hallo,

ich habe auch die Snom Softphone Variante getestet - das selbe Ergebnis.

Der Tip mit der Zertifikatgröße war aber gut. Meine waren zwar nur 512 Bit groß, ist aber trotzdem abgestürzt. Habe dann eins mit 1024 Bit erstellt und es klappte Dann noch mit 384 und 2048 Bit probiert; wieder abgestürzt.
Die Snoms brauchen also Serverzertifikate mit 1024 Bit.

Nur wie überprüfen sie dieses? Ich kann kein Zertifikat einer der RootCA hochladen. Habe die Frage mal an Snom weitergeleitet - mal schaun, was da kommt.

Torsten

 

[-KeX-]

Hallo Torsten,

Total komisch! Versteh ich nicht ganz warum die Snom nur ein Zertifikat mit 1024Bit verarbeiten können. Wenn du eine Rückmeldung von Snom hast, kannst du mir das bitte weiterleiten? Wär auch interessiert daran.

Läuft jetzt bei dir soweit alles?

Wann musst du denn mit deiner DA fertig sein?

chris...

 

[fhl.s02313]

Morgen,

habe die Antwort von Snom an dich per Email weitergeleitet. Mal sehen, ob da nochwas kommt.

Läuft jetzt bei dir soweit alles?

Ja, jedenfalls Serverzertifikate klappen jetzt soweit mit den Snoms 360 und Softphone, sowie mit MiniSIP. Das mit dem RootCA-Zertifikat in den Snoms laden werde ich heute probieren; meins ist momentan 2048 Bit groß - mal sehen :?
Und dann sind noch Clientzertifikate dran

Wann musst du denn mit deiner DA fertig sein?

11 Wochen noch :kotz:

Torsten