I'm trying to run following SPARQL-query on my local graphDB-Instance (GraphDB Free 9.4.1 on Windows).
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT * WHERE {
SERVICE <https://query.wikidata.org/sparql> {
?subj wdt:P31 wd:Q744913 ;
wdt:P625 ?coord ;
rdfs:label ?label
FILTER (lang(?label) = "en")
}
}
The query works without a problem on my personal computer.
But within my companies network, it doesn't, because we have a proxy.
I checked my proxy settings with a RDF4J-Java programm and they work perfectly fine.
[...]
System.setProperty("https.proxyHost", "<company_proxy>");
System.setProperty("https.proxyPort", "<company_proxy_port>");
System.setProperty("https.nonProxyHost", "localhost|127.0.0.1|<company_list>");
System.setProperty("https.proxyUser", "<user>");
System.setProperty("https.proxyPassword", "<password>");
[...]
I tried to set the same settings for GraphDB with different approaches
via the UI
via the C:\Users\XXXX\AppData\Local\GraphDB Free\runtime\conf\net configuration-file
via the C:\Users\XXXX\AppData\Roaming\GraphDB\conf\proxy.properties configuration-file
via the C:\Users\XXXX\AppData\Local\GraphDB Free\app\ configuration-file
All do something to the configuration, meaning I now see an error message and don't have a connection timeout anymore. Since I validated the settings with RDF4J I am guessing the problem is how I apply the configuration or there is a problem with parsing the configuration.
Edit:
I get an statuscode 407, Proxy Authentication Required.
I'm guessing, that graphDB doesn't accept the properties https.proxyUser and https.proxyPassword.
Did anybody had the same issue and has a solution? Or how could I debug this problem further?
ps. my password contains the '!' character. might this be the problem? I tried every escape mechanism i could think of (!, ^!, ^^!, all in "") but neither did work.
Edit 2.0:
The guys from ontotext found a bug and it was fixed with the release 9.5.0-TR14.
The proxy-configuration mentioned in this questions works now.
To closest possible scenario to simulate the issue with your proxy server was:
Download and install mitmproxy server
Trust the mitmproxy's certificate for all Java programs so GraphDB can use HTTPS connections to the proxy
# ~/.mitmproxy/mitmproxy-ca-cert.cer is the certificate shipped with the proxy
sudo keytool -importcert -file ~/.mitmproxy/mitmproxy-ca-cert.cer -alias mitmproxy -keystore $JAVA_HOME/jre/lib/security/cacerts
Start the proxy server with username and password
# The proxy will require username and password
mitmproxy --set proxyauth=testUser:testPassword
Start GraphDB and point it to the local mitmproxy server:
# Point the Apache HTTP Client to use the mitmproxy
./graphdb -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8080 -Dhttps.proxyUser=testUser -Dhttps.proxyPassword=testPassword
At this point, I was able to reproduce the HTTP 407 error, where the HTTPS client of GraphDB fails to negotiate the authenticating process with the proxy server. The same process works fine for the HTTP protocol, so this is how I have reached a workaround, which overcomes this glitch by specifying both the https.proxyUser and its http.proxyUser equivalent. The example works fine with your query and the mitmproxy server:
# Setup not only HTTPS but also HTTP connection
/graphdb -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8080 -Dhttps.proxyUser=testUser -Dhttps.proxyPassword=testPassword -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8080 -Dhttp.proxyUser=testUser -Dhttp.proxyPassword=testPassword
What you can try doing is setting up the 'graphdb.workbench.external-url' parameter to whatever URL/subpath your instance should reside at. This parameter is used for rewriting incoming requests and can help with API calls.
Related
I would like to send JMS messages to my local JBoss 7.2 server. For this purpose I tried using JMeter with the JMS Point-to-Point step. I configured everything as you can see in the picture below:
JNDI properties:
java.naming.security.principal = ca2
java.naming.security.credentials
= 12346578
What I've tried on the server side:
created an Application User (with the credentials in the JNDI properties)
deleted security realm from <http-connector name="http-remoting-connector"
connector-ref="default" security-realm="ApplicationRealm"/>
The server is up and running, but in both cases I got the following errors:
Response message: javax.naming.AuthenticationException: Failed to connect to any server. Servers tried: [http-remoting://127.0.0.1:8080 (Authentication failed: all available authentication mechanisms failed:
DIGEST-MD5: Server rejected authentication)] [Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
DIGEST-MD5: Server rejected authentication]
What else should I try?
These ca2 and 12346578 values don't look to be MD5-encoded to me, I think you need to use UsernamePasswordHashUtil in order to encrypt the credentials like
java -classpath /path/to/jboss/sasl/jar org/jboss/sasl/util/UsernamePasswordHashUtil <username> [realm name] <password>
Alternatively you can consider using jboss-ejb-client and send your message programmatically from the JSR223 Sampler and Groovy language, something like:
def config = AuthenticationConfiguration.empty()
.setSaslMechanismSelector(SaslMechanismSelector.NONE.addMechanism("DIGEST-MD5")).useName("ca2")
.usePassword("12345678");
def ctx = AuthenticationContext.empty().with(MatchRule.ALL.matchHost("127.0.0.1"), config);
Turned out my configuration was completely wrong.
I apologize to everyone who tried to help me. It was a great lesson to learn for me.
Here is what I had to do, and you should consider if you are in a similar situation:
Remove jboss-client.jar from jmeter's lib/ext folder. (It caused the connection to close too soon for some reason)
Change JMeter Poin-to-Point step's Communication style to
request_only
Create a JBoss Application user and add it to the guest group
(./add-user.sh -a --user ca2 --password 12345678 -g guest)
Activate the jboss profile in server config (add the system property:
<property name="spring.profiles.active" value="jboss"/>)
And of course configure the JMS consumer properly in the Java code (one can check in the management console whether the consumer exists)
Thanks for everyone who helped me.
I'm having issues connecting to a database hosted on a server using IntelliJ and JDBC. With the command line, the command:
ssh username#server -L 11100:ct1:28017 -N
creates a tunnel successfully and the command:
psql db_name -h localhost -p 11100 db_username
connects to the database fine and allows me to use it. How would this be translated correctly into the IntelliJ Data Sources and the SSH tunnel tools?
At the moment, for the SSH tunnel settings I have:
Proxy Host: server
Port: 22
Proxy user: username
For the general tab I have:
host: localhost
port: 28017
database: db_name
user: db_username
The connection returns successfully after testing the connection. Inside my program I have:
Connection connection = DriverManager.getConnection("jdbc:postgresql://localhost:28017/db_name", user, password);
The URL parameter is the one generated by IntelliJ. This however gives me an error "Connection to localhost:28017 refused."
Any ideas on what I am doing wrong?
Here's my setup via intellij if anyone is looking for simple solution without external libraries.
Open Database view (View -> Tool Windows -> Database).
Add new DataSource (right-click, New -> Data Source ->
Postgres/Mysql). In host, use 127.0.0.1 (not localhost, sometimes
localhost is not properly resolved).
Fill in rest of the fields as configured on your remote host.
Now click on SSH/SSL tab and configure ssl tunnel:
Do you connect to SSH server from a java client like SSHJ (https://github.com/hierynomus/sshj) ?
The URL on your DriverManager seems wrong: try port 11100 instead.
If the error is Exhausted available authentication methods ❶, make sure that the passphrase ❷ is provided if required. This is easy to forget because the passphrase is often supplied automatically by the OS keyring manager, which makes it seem like the key does not have one.
The credentials in ❸ are for Postgres. These will not work with peer authentication. In my case, I needed this in pg_hba.conf:
hostnossl all rdahl 127.0.0.1/32 md5
The proxy host and user in ❹ are for the ssh server as seen from the client.
The docs from JetBrains are odd and left me in doubt if this is just using an existing SSH tunnel, or if it creates one. It creates one.
The Test Connection buttons in the two dialogs both trigger the same test.
In the company that I work we have a server GF 3.1.1 (JDK 6) with CAS which does the authentication of the users in another system. After the last update of Firefox (v. 39x) we are getting the follow information from the browser:
mydomain.com SSL received a weak ephemeral Diffie-Hellman key in
Server Key Exchange handshake message.
And it is not possible to access the site without this workaround or using another browser.
In chrome I can access normally but if I look at the connection properties it says:
Your connection is encrypted with obsolete cryptography.
The connection uses TLS 1.0.
The connection is encrypted using
AES_128_CBC, with SHA1 for message authentication an DHE_RSA as the
key exchange mechanism.
I can't configure all the browsers of our customers or say them only use chrome. Maybe in future chrome can do the same. So my solution is configure the server properly. The problem is that I don't know how can I do that.
I found in GF where I can do the configuration in Configurations > server-config > Network Config > Protocols > http-listner-2 > SSL
Then I found here a blacklist and a whitelist of some ciphers that are recommended to use. I tried to remove all in black and put all those in white. But I still have the issue. I think this list may be out of date.
I appreciate any help.
Finally. I found a solution.
I search a lot and I could find a solution, so I tried to test one by one of the ciphers. So, to work ( I am not saying that is the right way). I had to do this:
At:
Configurations > server-config > Network Config > Protocols > http-listner-2 > SSL
Add all the ciphers available
Remove all the Diffie-Hellman ciphers
Save
After that our application can be opened at any browser again. I hope it may help someone.
For admin:
Configurations > server-config > Service HTTP > Listeners HTTP > admin-listner > SSL
Add all the ciphers available
Remove all the Diffie-Hellman ciphers
Save
Restart
Edit: Comparing with the whitelist here the remaining ciphers that would be part of a new whitelist are:
Whitelist
TLS_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
I just encountered this problem as well with Chrome and the admin console. The way I got around it was to delete the current ssl certificate for the listener and recreate it using a specific set of ciphers with the --ssl3tlsciphers option. For me it was the admin-listener so first I deleted the current default certificate:
asadmin delete-ssl --type http-listener admin-listener
Then I recreated it using the following command:
asadmin create-ssl --type http-listener --certname s1as --ssl3tlsciphers SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV,SSL_RSA_WITH_NULL_MD5,SSL_RSA_WITH_NULL_SHA,SSL_DH_anon_WITH_RC4_128_MD5,TLS_DH_anon_WITH_AES_128_CBC_SHA,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA admin-listener
I noticed that simply deleting the default certificate doesn't remove all references to it in the domain.xml file. I haven't been able to find the proper way to do this. I just used trial and error. Another method is to modify the domain.xml file where the ssl element for the listener is defined and add the attribute "ssl3-tls-ciphers":
<ssl ssl3-tls-ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_DES_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV,SSL_RSA_WITH_NULL_MD5,SSL_RSA_WITH_NULL_SHA,SSL_DH_anon_WITH_RC4_128_MD5,TLS_DH_anon_WITH_AES_128_CBC_SHA,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA" classname="com.sun.enterprise.security.ssl.GlassfishSSLImpl" cert-nickname="s1as"></ssl>
Both methods require a restart of glassfish.
Thanks, Sertage, that worked!
However, it is also necessary to fix the Protocol for the admin port (usually 4848). (It should, of course, use HTTPS too!)
But, in GF 3.1.2.2, the Protocol 'admin-listener' appears to be kind of pointing to the Protocol 'sec-admin-listener', and that does not have a 'SSL' tab. Changing the SSL parameters the Protocol 'admin-listener' results in an error message, saying 'Could not apply changes. No Configuration found for configs.config.server-config.network-config.protocols.protocol.admin-listener.ssl'. Any suggestions on how to configure the admin port?
I'm running Jenkins CI inside a corporate network which uses a proxy for internet access.
I tried to configure proxy details in Plugins->Advanced, but even though the credentials are correct (yeah, I checked it a bunch of times), it cannot validate "Test URL" even on http://google.com and returns
Failed to connect to http://google.com (code 407).
Strangely, Jenkins is still able to download plugins itself (whoa!), but totally unable to connect to any HTTP resource. The message that outputs from the console is:
←[0mApr 16, 2015 1:58:56 PM
org.apache.commons.httpclient.HttpMethodDirector pro
cessProxyAuthChallenge INFO: Failure authenticating with NTLM #proxyrye.asg.com:80 Apr 16, 2015 2:09:09 PM
org.apache.commons.httpclient.HttpMethodDirector execute WithRetry
INFO: I/O exception (java.net.ConnectException) caught when processing
request: Connection timed out: connect Apr 16, 2015 2:09:09 PM
org.apache.commons.httpclient.HttpMethodDirector execute WithRetry
INFO: Retrying request Apr 16, 2015 2:09:10 PM
org.apache.commons.httpclient.auth.AuthChallengeProcesso r
selectAuthScheme INFO: ntlm authentication scheme selected ←[31mApr
16, 2015 2:09:10 PM org.apache.commons.httpclient.HttpMethodDirector
au thenticate SEVERE: Credentials cannot be used for NTLM
authentication: org.apache.commons.h
ttpclient.UsernamePasswordCredentials
org.apache.commons.httpclient.auth.InvalidCredentialsException:
Credentials cann ot be used for NTLM authentication:
org.apache.commons.httpclient.UsernamePasswo rdCredentials
at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme
.java:332)
We had this issue a rather long time with our Jenkins behind our company's proxy. The other day they changed the order of authentication schemes our proxy desires. This was the day our Jenkins stopped connecting to the internet.
Obviously Jenkins is not able to connect via a proxy that requires NTML authentication. This was what lead me to issue an improvement for Jenkins to extend the proxy configuration screen. During the work on the extension I discovered that Jenkins does not make use of all proxy related system properties, therefore it cannot work with NTLM.
As such the answer for a proxy that allows only NTLM authentication is: it will not work via the Jenkins UI.
But if your proxy allows other authentication schemes, you can follow our workaround, it is rather simple: add the java system property -Dhttp.auth.preference="basic" to your Jenkins startup script or to that one of your container.
This will force the underlying libraries and Java mechanisms Jenkins makes use of to connect to your proxy using basic authentication, not NTLM.
for Java JDK8 and above, Oracle has disabled basic auth tunnelling for Basic authentication. If you want to use Basic mode again (security will be compromised), execute Jenkins adding this parameter to your JAVA_OPTS variable
"-Djdk.http.auth.tunneling.disabledSchemes="
default value is
"-Djdk.http.auth.tunneling.disabledSchemes=Basic",
as Basic scheme is DISABLED by default, it will return HTTP 407 error even if your credentials were OK.
more on link https://issues.jenkins-ci.org/browse/JENKINS-48775 Thanks to Israel Romero Fiji
The below solution worked for me for the 407 problem in Windows 7 machine.
1. Stop Jenkins from Windows Services
2. Goto Services.msc > Jenkins > Right Click > Properties > Logon > This account and type in your username and password
3. Click Apply and Ok
3. Start Jenkins
I was getting this error while running jenkins with jetty server on jdk 8.
To resolve issue follow below steps:
Step 1:
Open URL https://updates.jenkins.io/ in browser
Step 2:
To export the Intermediate certificate:
Internet Explorer -> Tools -> Internet Options -> Content -> Certificates ->
Go to Trusted Root Certification Authorities Tab and find out the DST Root CA X3 certificate. Then Export the Certificate:
Select Certificate -> Export -> DER encoded Binary Format -> Save
save the certificate as jenkins.cer (for me it was saved to C:\jenkins\jenkins.cer
( From Firefox -> Tools -> Options -> Advanced -> Encryption -> View Certificates )
Step 3:
create keystore with name cacertskeystore
JAVA_HOME\bin\keytool -keystore C:\jenkins\cacertskeystore -genkey -alias cacerts
Step 4:
Add jenkins.cer to cacertskeystore using below command
JAVA_HOME\bin\keytool -import -trustcacerts -Keystore C:\jenkins\cacertskeystore -alias jenkins -file C:\jenkins\jenkins.cer
Step 5: Start jetty server with below command
JAVA_HOME\bin\java -DJENKINS_HOME=C:/jenkins/home -Djavax.net.ssl.trustStore=C:/jenkins/cacertskeystore -Djavax.net.ssl.trustStorePassword=password-provided-while-creating-keystore -jar jenkins.war --httpPort=8080--httpListenAddress=localhost
I found this question while affected by bug: https://issues.jenkins-ci.org/browse/JENKINS-48775
The temporary workaround is to open the Jenkins script console and type
ProxyConfiguration.open(new java.net.URL("http://jenkins.io")).content
Since it's an http url, and not an https url, it will refresh some caches and make the plugin manager work with the proxy settings, at least for some time. See the bug report for more details.
If you parse the exception, it states
Credentials cannot be used for NTLM authentication
So according to https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch04s09.html you might need to provide a domain name as well.
If your proxy is using Microsoft’s NTLM authentication scheme, then you will need to provide a domain name as well as a username. You can place both in the User name field: just enter the domain name, followed by a back-slash (\), followed by the username, such as “MyDomain\Joe Bloggs”.
Maybe that's the issue?
I ran into this issue today, and it finally ended up being a space at the end of the Spira URI in the Spira configuration. Must've been a bad copy and paste.
I got the Failed to connect to http://google.com (code 407) error in Test. But jenkins can check new version and install plugins&updates.
Put in credentials regardless of the Test. Then Save and go to available plugins/check jenkins version to check if it works.
Simple Hack:
Try using the IP of the domain rather than the address. -Dhttp.auth.preference="basic" actually didn't work for me :(
PS. Change both the browser and proxy and the Jenkins proxy to the IP
I have also faced same issue of jenkins-proxy-407-error
I have found work around for that, I Hope it will be useful for other users :
You can install Cntlm Authentication Proxy , it stands between your applications and the corporate proxy, adding NTLM authentication on-the-fly.
See here http://cntlm.sourceforge.net/
Once you install CNTLM, add your NTLM credentials in a file cntlm.ini . You can also configure Listen port or default to 3128 .
Find detailed instruction of CNTLM installation here
https://vijiboy.wordpress.com/2018/03/14/configure-cntlm-to-generate-hash-for-your-password-h-and-verify-m/
Start CNTLM service and go to jenkins, add
host: host name or localhost
port: Listen port specified in cntlm.ini or default 3128
keep username and password blank and you are set to use Jenkins.
Solution is so simple
If you tried to edit
jdk.http.auth.tunneling.disabledSchemes=Basic
to
jdk.http.auth.tunneling.disabledSchemes=
at location C:.......\java-1.8.0-openjdk\jre\lib\net.properties
Then later try to enter
fill this section with proper entries
Done.
Check this screenshot
I connect to a web service with this client that work fine:
WSCSI WSCS = new WSCSI("http://localhost:8080/ServiceV2/services/WSCSISoap?wsdl","WSCSI","WSCSISoap");
IScoring instance = new ScoringCFA(WSCS);
assertEquals(true, instance.statusService());
I need to use SSL, So i change the url to:
https://localhost:8181/ServiceV2/services/WSCSISoap?wsdl
And add this in the VM Options:
-Djavax.net.ssl.trustStore="C:\cacerts.jks"
('Keytool -list -keystore "C:\cacerts.jks', when i run this command i see that the certificate that i need is there)
When i run the client get this error:
java.security.cert.CertificateException: No name matching localhost found.)
That's probably because the cert you're using is issued against a specific hostname (www.myhost.com). Try the solution in this article.
But be warned, the code sample is only intended for localhost testing, remove it once you move onto the integration/assembly testing on a proper server.
Sounds to me that disabling SSL hostname verification might work for you. Another example here.