PDA

View Full Version : SSL-Problem mit jdbc



Seiten : [1] 2

gue_br
02-10-08, 13:33
Hallo!

Ich habe ein Riesenproblem mit dem jdbc-Treiber um eine MS SQL Server 2005 Datenbank von der i5 aus anzusprechen.
Ich habe die Ausgabe der Java-Konsole mit OVRDBF STDERR TEST/STDERR in eine Datei umgeleitet und erhalte da folgenden Fehlereintrag:

02.10.2008 14:21:10 com.microsoft.sqlserver.jdbc.TDSChannel enableSSL

WARNUNG: TDSChannel ( ConnectionID:1
TransactionID:0x0000000000000000)
SSL handshake failed: null

com.microsoft.sqlserver.jdbc.SQLServerException: Der Treiber konnte keine sichere Verbindung mit SQL Server über die SSL (Secure Sockets Layer)-Verschlüsselung herstellen. Fehler: null.

Ich habe bereits in vielen Foren gestöbert (auch hier), aber leider hat nichts geholfen. Weder der Umstieg auf sqljdbc_1.1.jar, noch ein anderer Treiber.

Vom Windows-PC aus habe ich das Tool DBVisualizer (Free 6.0.14) im Einsatz, mit dem ich ebenfalls über einen jdbc-Treiber auf den SQL-Server zugreife. Von da aus gingen bisher alle Treiber, die ich probiert habe.

Nach über zwei Tagen vergeblichen Herumprobierens bin ich nahe am Verzweifeln und bin für jeden Rat dankbar.

Mit freundlichen Grüßen

Günter Bretterebner

Fuerchau
02-10-08, 13:44
So wie ich das sehe brauchst du keine SSL-Verbindung zum SQL-Server.
Versuche es mal ohne SSL.

gue_br
02-10-08, 14:30
Hallo!

Danke für die schnelle Antwort.

Aber wo sage ich dem Treiber, der JVM, der i5 oder welchem Ding auch immer, daß ich kein SSL will?

KM
02-10-08, 14:37
Hallo,

gib im Connection-String mal die Option encrypt=false an. Standardmäßig wird beim SQL-Server 2005 glaube ich die Verschlüsselung aktiviert.

Gruß,
KM

gue_br
02-10-08, 14:51
Hallo,

gib im Connection-String mal die Option encrypt=false an. Standardmäßig wird beim SQL-Server 2005 glaube ich die Verschlüsselung aktiviert.

Gruß,
KM

Hab ich auch schon probiert. Soweit ich es bis jetzt verstanden habe, steuert dieser Parm nur, ob später die Daten verschlüsselt übertragen werden.
Die Anmeldung scheitert aber schon an der SSL-Verbindung.

Fuerchau
02-10-08, 15:14
Ich glaube, hier wirst du fündig:
"WARNING: TDSChannel" When Attempting to Connect - TechNet Forums (http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2367299&SiteID=17)

gue_br
02-10-08, 19:16
Ich glaube, hier wirst du fündig:
"WARNING: TDSChannel" When Attempting to Connect - TechNet Forums (http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2367299&SiteID=17)

Danke, da hab ich das mit der verschlüsselten Anmeldung gelesen und das der Parm "encrypten=false" nur für das was danach gilt, gelesen.

Werd mir das mit der JRE-Konfiguration für das JSSE nochmal genau durchlesen und anschauen.

Es ist halt mühsam, wenn man von der grünen Wiese (bzw. Schirm) kommt und in so ein, meiner Meinung nach, komplexes Gebiet vorstößt.

Günter

gue_br
03-10-08, 10:29
Ich habe noch eine Frage zum Speicherort des sqljdbc.jar - Files.
Da ich mittlerweile so ziemlich alle Versionen von 1.0 über 1.1, 1.2 bis 2.0 des Microsoft JDBC-Treiber für SQL Server 2005 ausprobiert habe und nichts geholfen hat, stellt sich mir die Frage, ob die überhaupt verwendet/aufgerufen wurden.

Ich bin nämlich jetzt hergegangen und habe mit wrkenvvar einen falschen Eintrag in CLASSPATH zum Treiber hin gemacht (ich setze das im RPG). Und siehe da, es hat trotzdem gleich nicht funktioniert wie sonst auch.

Eigentlich bin ich davon ausgegagnen, daß der Treiber in dem im CLASSPATH angegeben Pfad liegen sollte:
/QIBM/UserData/Java400/ext/sqljdbc.jar

Oder irre ich mich da.


Danke,
Günter

BenderD
03-10-08, 11:38
ich würde die Finger von dem Wackelhaufen java calls aus RPG lassen. Das wird nie stabil, da die JVM implizit gestartet wird (und wenn das im Job ein anderer Aufruf gemacht hat, dann passts wieder nicht). ich würde auch irgendwelche Treiber nicht global vernageln (korrekter Weise müsste der auch in ...ProdData... liegen), über welchen Weg auch immer.
Ein Java Environment gehört mit java gestartet, da kann man den Classpath per Parameter einstellen und auch z.B.: -verbose angeben, damit man sieht, was da wirklich aufgerufen wird. Wenn ich das aus RPG aufrufen will, dann macht man da einen Serverdienst draus und lässt den asynchron per DataQ oder MSGQ mit dem RPG Teil kommunizieren. Dann wird das ganze auch performat, skalierbar, stabil und wartbar.
Zu letzterem habe ich ein Framework AppServer4RPG auf meiner Homepage und bei Sourceforge.net als OpenSource veröffentlicht.

D*B



Ich bin nämlich jetzt hergegangen und habe mit wrkenvvar einen falschen Eintrag in CLASSPATH zum Treiber hin gemacht (ich setze das im RPG). Und siehe da, es hat trotzdem gleich nicht funktioniert wie sonst auch.

Eigentlich bin ich davon ausgegagnen, daß der Treiber in dem im CLASSPATH angegeben Pfad liegen sollte:
/QIBM/UserData/Java400/ext/sqljdbc.jar

Oder irre ich mich da.


Danke,
Günter

gue_br
06-10-08, 06:21
ich würde die Finger von dem Wackelhaufen java calls aus RPG lassen. Das wird nie stabil, da die JVM implizit gestartet wird (und wenn das im Job ein anderer Aufruf gemacht hat, dann passts wieder nicht). ich würde auch irgendwelche Treiber nicht global vernageln (korrekter Weise müsste der auch in ...ProdData... liegen), über welchen Weg auch immer.
Ein Java Environment gehört mit java gestartet, da kann man den Classpath per Parameter einstellen und auch z.B.: -verbose angeben, damit man sieht, was da wirklich aufgerufen wird. Wenn ich das aus RPG aufrufen will, dann macht man da einen Serverdienst draus und lässt den asynchron per DataQ oder MSGQ mit dem RPG Teil kommunizieren. Dann wird das ganze auch performat, skalierbar, stabil und wartbar.
Zu letzterem habe ich ein Framework AppServer4RPG auf meiner Homepage und bei Sourceforge.net als OpenSource veröffentlicht.

D*B

------------------------------------------