We have implemented APNS connectivity using notnoop. We have been testing it for last 5 months on development and UAT environment and other environment. Things were working as expected but post deployment to production environment we are having tough time getting it work, GCM is working fine it is only APNS were we have tough time.
Initially there was connectivity issue from firewall which we have got opened to connect to gateway.push.apple.com on 2195 as earlier system was throwing connection timeout.
Now system is throwing No Trusted Certificate found I have described below the detail steps we have already taken to debug this.
Please note this is happening only when i deploy it on production that too when it is run inside Tomcat 8.0. We did small POC to test if it can work outside tomcat and it is working properly using same certificate from same absolute path.
We did try after changing the implementation to use absolute path of certificate as shown below
APNS.newService().withCert(PRODcertificatePath, PRODcertificatePassword)
The program is configured to use .withProductionDestination() if it is using production certificate and vice versa so this issue is also taken care.
Then we also tried using ClassLoader InputStream iss = ClassLoader.getSystemResourceAsStream("Axis-APNS.p12")
Yes we do have JKS file on production whose detail is configured in server.xml something like below
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" sslProtocol="TLS" keystoreFile="/root/cert"
Now we are out of idea to debug and find the root cause, Any suggestion, question is most welcome.
As a matter of workaround, i have redesign my system. Instead of running from inside tomcat, Have made it as standalone application using Quartz batch job and system is running properly. Once i get time to find out why tomcat is not able to pick correct certificate, will upate you guys on it. Thank you very much for your time... email me if you need anymore help on above matter. Thanks, Amarjeet
Related
Troubleshooting someone elses problem over the phone.
The error is trying to connect from one server to another servers db over ssl.
The error message is: 'requires a valid client certificate'
I've done everything to ensure that they have created the correct cert.
I had them debug=yes ssl:handshake and send me the logs.
In their logs they have nothing set for the keystore and the wrong path for the truststore.
Herein I think lies the issue. We have an executable jar that reads the paths and passwords for the keystore/truststore and sets the values via calls such as System.setProperty("javax.net.ssl.keyStore", config.getKeyStore());
from within the executable. I've verified at least locally that I can communicate over SSL from 1 server to anothers database in our test environment and all is fine. If I were to remove all of the settings then the error log generated by the ssl:handshake gives me the 'requires a valid client certificate'.
I'm told that the destination server with the DB has its pg_hba file
set properly to accept the communication over SSL from the specified
id.
I've verified that the cert is valid from the CA.
The only thing that I can think of is that the executable jar is not setting the values to the System via the code System.setProperty("javax.net.ssl.keyStore");
Is this a configuration that needs to occur to the Red Hat server to allow the jar to set system properties or is this at the file permission level or ? ? ?
I'm at a loss here and would appreciate any guidance on this issue.
Very difficult environment. I'm on the North-East tasked to assist someone in Midwest to trouble shoot them trying to connect to our Database in the South-West. I have no access to the actual servers and have to try and debug over the phone.
I am trying, for the first time, to run a java EE 7 web app without an IDE and struggling through the learning curve. To keep things simple I have started with Glassfish 4.1 and Derby 10.11.1.2 which is what I used for development.
My current problem is an error configuring the connection pool on the Glassfish web interface. The error is 'Connection authentication failure occurred. Reason: Userid or password invalid'. However I have ij runing in a dos prompt and the Glashfish web console in Chrome.
from ij I can type 'connect 'jdbc:derby:localhost:1527/databasename;user=username;password=password'; and I connect fine and can look at tables, etc. In the Glassfish web console I have name/value pairs with the same 'user' and 'password' values and it fails (exact same letters & case). I've tried changing the 'databaseName' property to make sure the error wasn't misleading and confirmed it has found the database correctly.
At face value, the error message seems wrong as I have proven from the DOS window. I am sure I am doing something wrong but am lost at how to diagnose it. Any suggestions?
More details of the steps taken: (Although I am sure some of these steps superceed others my lack of success has me in the mindset that redundancy is better than omission - all-in-all it seems much more complicated than it needs to be for a basic setup). My target is Wildfly but Glassfish documentation is better so I figured I would start there.
relevant Windows environment variables:
JAVA_HOME=C:\Program Files\Java\jdk1.8.0_40
DERBY_HOME=%JAVA_HOME%\db
DERBY_INSTALL=%DERBY_HOME%
JAVADB_HOME=%DERBY_HOME%
GLASSFISH=C:\Program Files\Java\GlassFish-4.1
Path=%JAVA_HOME%\bin;%DERBY_HOME%\bin;%GLASSFISH%\bin;%GLASSFISH%\glassfish
CLASSPATH=%DERBY_HOME%\lib\derbynet.jar;%DERBY_HOME%\lib\derbytools.jar;%DERBY_HOME%\derbyclient.jar;%DERBY_HOME%\lib\derbyrun.jar
WILDFLY_HOME=C:\program files\java\wildfly\8.2.0.Final
sysinfo shows all the right paths and versions
Copied many of the derby jars from %derby_home%\lib to %glassfish%\glassfish\domains\domain1\lib\ext per a post by BalusC. I think classpath duplicates this it but can't hurt
Started Domain 'asadmin start-domain' defaulting to domain 1
Started DB by changing directories and using java. Wanted to use 'asadmin start-database --dbhome DB path' but this always started the wrong version. Glassfish and JDK both package derby/javadb and I couldn't figure out how to upgrade Glassfish or start the correct version any other way
cd \users\john\.netbeans-derby (root of the DB created by Netbeans)
Java –jar “%derby_home%\lib\derbyrun.jar" server start
connect browser to 'localhost:4848' to create JDBC connection pool and resource
connection pool: pool name=connectionPool, resource type=javax.sql.DataSource, DB driver Vendor=Derby, introspect was not enabled (found very little documentation to explain what it is) - step 2 was left as defaults
editing connectionPool - enabled Ping on General tab to identify errors, Additional Properties tab: changed User to DB username, left other attributes as default, added... password=db password, databaseName=ClubScoring
errors were presented along the way which prompted setting each attribute. No error was presented for lack of URL but tested steps below with and without URL=jdbc:derby://localhost:1527/ClubScoring
jdbc resources. Added jdbc/ClubScoring, pool=connectionPool => selected and enabled
starting db from correct directory using 'asadmin start-database' does let the application find the correct DB but it crashes since the DB was created with version 10.11.1.2 and this command starts the Glassfish version of 10.10.2.0
Sorry for making this so long but I haven't found anywhere that lays out all of the steps in a simple fashion and figured the details would save time in the long run.
I was dealing with this issue today and found a solution:
https://db.apache.org/derby/docs/10.14/ref/rrefattribsecmech.html
Basically the only security options allowable (as far as 10.14 is concerned) is 3, 4 and 9.
4 is the default and means "Just UserID". You would think this means that as long as a UserID is given, you could connect. But having both set appears to be an issue.
In order to use a (clear text) password and userID, you have to specify 3. It works also if the attribute is deleted or 0 as well but I don't think you get any security that way.
I'm trying to monitor my WLP v8.5.5 with JConsole.
My Liberty profile is up and running and has SSL properlly configured.
I also have configured as features the monitor-1.0 and restConnector-1.0.
After that I sftp'ed from my WLP the restConnector.jar to my machine and created a keystore on my machine as described here
After that I'm trying to start JConsole with this command:
jconsole -J-Djava.class.path="C:\Program Files\Java\jdk1.7.0_67\lib\jconsole.jar;
C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar;
<whereIDownloaded>\restConnector.jar"
-J-Djavax.net.ssl.keyStore="<locationToCreated>\keystore.jks"
-J-Djavax.net.ssl.keyStorePassword=<password>
-J-Djavax.net.ssl.keyStoreType=jks
-J-Dcom.ibm.ws.jmx.connector.client.disableURLHostnameVerification=true
However, when I try to connect to my WLP via remote with the string:
service:jmx:rest://<ip>:<httpsPort>/IBMJMXConnectorREST
As a credential I'm passing a user configured on <administrator-role>.
I get a JConsole error saying:
Secure connection failed. Retry insecurely?
I don't get why I'm seeing this error, and I don't see any logs to see why it failed.
My next step if getting the keystore from WLP and try that on my machine but I don't think that makes much sense.
Does anyone have any suggestion on where should I look for logs or on that I'm doing wrong?
Thanks in advance!
Reference:
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.wlp.nd.doc/ae/twlp_mon.html?cp=SSAW57_8.5.5%2F1-3-11-0-6&lang=en
Ensure you don't have localConnector-1.0 feature. If you have that, please remove it. You can find more details here Remote monitoring of Liberty with Health Center. Although it discusses Health Center connection, I was testing using JConsole also.
UPDATE
You might be invoking console with incorrect params - it should be trustStore not keystore see below. And for start use key.jks copied from Liberty (as you need Liberty certificate as trusted)
jconsole -J-Djava.class.path=%JAVA_HOME%/lib/jconsole.jar;
%JAVA_HOME%/lib/tools.jar;
%WLP_HOME%/clients/restConnector.jar
-J-Djavax.net.ssl.trustStore=key.jks
-J-Djavax.net.ssl.trustStorePassword=Liberty
-J-Djavax.net.ssl.trustStoreType=jks
For details check Configuring secure JMX connection to the Liberty
As an additional note - you must not have a webAppSecurity entry with loginFormURL set in your server.xml as this will cause the JMX login to fail (e.g., <webAppSecurity loginFormURL="login.html"/> is problematic). Each individual WAR needs to set their own login-config and not rely on any global method of configuring logins.
`
I'm connecting to the WebSphere instance from the stand-alone Java app which is quite trivial:
InitialContext initCtx = new InitialContext();
That code was working perfectly in WebSphere 7, but after updating to WebSphere 8.5 I got the following exception:
Caused by: org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 completed: No
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1276)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1457)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1164)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1423)
at com.ibm.rmi.corba.ClientDelegate.request(ClientDelegate.java:1886)
at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1379)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:458)
at com.ibm.WsnBootstrap._WsnNameServiceStub.getProperties(_WsnNameServiceStub.java:38)
at com.ibm.ws.naming.util.WsnInitCtxFactory.mergeWsnNSProperties(WsnInitCtxFactory.java:1441)
... 43 more
After research, I've fout out that IBM support page, which said to go to CSIv2 inbound and outbound settings (by me, Admin Console->Security->GlobalSecurity->RMI/IIOP security) and set the transport to SSL-Supported.
However, it didn't change anything. I've tried to change the 'Cleint certificate authentication' to Never, and Transport to TCP/IP for both CSIv2 inbound and outbound, but still without success. The error persisted until I've turned off 'Enable administrative security', which is not an option, because I need to enable 'Application Security' (the application logic depends of that).
How can I make my code working again? Everything was OK on WebSphere 7.
My research on this issue may prove useful to others;
WebSphere 8 changed the default setting of RMI/IIOP SSL security from
'supported' to 'required'. If you want a secure connection you'll need
to get the certs from the server and set Java system properties to files that specify the location of the certs;
com.ibm.CORBA.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/sas.client.props
com.ibm.SSL.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/ssl.client.props
If this doesn't work, you'll need to start debugging by setting the following System properties;
com.ibm.CORBA.Debug=true
com.ibm.CORBA.CommTrace=true
com.ibm.CORBA.Debug.Output=/tmp/corba.log
By studying this log and orb trace logs in the working directory, I found that the client failed to establish an ephemeral TCP connection to the server at "port=0". No mention of SSL in the logs! I wrote a small app to test my code running as a java console app and found that the SSL connection was successful and it worked fine. By diff'ing the logs, I found that only in the good case, the JVM was finding a local file 'orb.properties'. I then found that in my problem case, my test app was using a different JVM and my real app was using a JVM that had no 'orb.properties'. I could resolve the problem in a number of ways .. e.g. by including an orb.properties in my application and injecting the contents as System properties.
In my case switching CSIV inbound to SSL-Supported from SSL-required and restarting the server helped.
The error description
org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07
is very vague and happens under many, not directly connected circumstances.
In my case it had nothing to do with RMI/IIOP security settings, but it was a classpath problem. I was still using old version of com.ibm.ws.webservices.thinclient.
Switching to thinclient 8.5.0, as well as setting the launch JRE to standard (Oracle) JVM has fixed the problem.
I want to send EMails from a JBoss 7 application. The SMTP server needs a TLS connection with a self signed certificate. If I try to send a EMail I get a SSLHandshakeException because the server certificate cannot be checked. To fix this I have add this: http://springinpractice.com/2012/04/29/fixing-pkix-path-building-issues-when-using-javamail-and-smtp/ (putting the SMTP server certificate into a java truststore file)
My problem is now how to set the truststore file to JBoss 7?
I known at stackoverflow and on other forums there are several answer for that propblem. But I didn't found the right.
I have already tried followings:
adding JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=/home/stewert.c-on/data/projects/keystore/devel.truststore -Djavax.net.ssl.trustStorePassword=123456" to:
jboss-as-7.1.1.Final/bin/standalone.conf
jboss-as-7.1.1.Final/bin/domain.conf
jboss-as-7.1.1.Final/bin/appclient.conf
adding <jsse keystore-password="123456" keystore-url="/home/stewert.c-on/data/projects/keystore/devel.keystore" truststore-password="123456" truststore-url="/home/stewert.c-on/data/projects/keystore/devel.truststore"/> to jboss-as-7.1.1.Final/standalone/configuration/standalone.xml
But if I check at runtime the system environment variable with 'System.getProperty("javax.net.ssl.trustStore")' I get in every case null!
My environment:
Linux
JBoss 7.1
JDK 7
I'm starting JBoss inside of eclipse Juno
Anybody knows what's going wrong? Where must I set the truststore?
Thanks,
Steffen
Someone asked on the JBoss forum "javax.net.ssl.trustStore - only way to specify client trust?", and the answer is basically "yes".
Their approach was to set that in a system-properties element in the server config XML, which seems like the best way to me too. Better than grubbing about in the run configuration files!