We Keep Coding

Kong certificate error - no SNI provided by client

Using Kong v.2.8.0-alpine docker version, I get SSL errors "no SNI provided by client, serving default SSL certificate" (which is the internally generated KongHQ cert). My host certificates are loaded against the /certificates endpoint with the desired SNI entries (and viewing the certificate from the admin endpoints show my certificates).
Using a springboot application (v2.6.2) or a standalone java rest client, SSL calls are successful through Kong when the server name (https://this.host.com:8443/some-endpoint) is used as the host. However, when making the same call within the Docker network by referencing https://kong:8443/some-endpoint, the call fails with a handshake failure related to SNI being missing. Viewing the java ssl:handshake debug output, the server_name extensions is present on the fqdn host configuration, but is missing when using the docker container name.
The version of Java used is 1.8_0_212 and 1.11.
I am unable to reproduce this issue with Python or curl.
Is there a way to override the Kong default certificates?

WebLogic Hostname verification problems

I have the following setup using Weblogic 12c on a Centos8 server:
There is one domain, that consists of two machines (machine0 and machine1).
Nodemanager is configured for both, and the admin console also tells me, that both nodemanagers are reachable. Both of the machines ip adresses are set in the /etc/hosts file to machine0 and machine1.
Hostname verification is disabled in the admin server, as well as in the nodemanager's properties files. So far so good.
Furthermore I'm using custom certificates in two jks stores (ID nd Trust) which have been verified to work in a different scenario (just using localhost in two "machines").
Now I create a new managed server via the admin console (doesn't matter for which machine) with hostname verification turned OFF in the SSL tab (all other necessary SSL settings are valid).
If I try to start it right after creation via the admin console (nodemanager is reachable!) the server log tells me:
<BEA-090960> <The server's SSL configuration is not available. There will potentially be SSL handshake failures.>
<BEA-090924> <JSSE has been selected by default, since the SSLMBean is not available.>
<Security> <BEA-090908> <Using the default WebLogic SSL Hostname Verifier implementation.>
Leading to:
<Info> <Management> <BEA-141298> <Could not register with the Administration Server: java.rmi.RemoteException: [Deployer:149150]An IOException occurred while reading the input.; nested exception is:
javax.net.ssl.SSLKeyException: Hostname verification failed: HostnameVerifier=weblogic.security.utils.SSLWLSHostnameVerifier,
But it also tells me, that it was able to load trusted certs from my defined Trust store:
<Security> <BEA-090169> <Loading trusted certificates from the jks keystore file /home/iffuw/Documents/keystores/TrustStore.jks.>
The only way to start the server right after creation and correct configuration in the described manner is to add this option to the "startWeblogic" script in the domain's /bin folder.
JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.security.SSL.ignoreHostnameVerification=true"
to disable hostname verification via a JVM argument.
Once the server booted up, I can comment out that line again, since ALL SSL settings seem to have taken effect now.
So it looks like all custom SSL settings (my custom ID and trust stores, otherwise no SSL connection to the AdminServer would be possible) are transferred at the first server start via admin console and nodemanager, but NOT the setting to ignore hostname verification.
Am I missing something here?

Postgresql JDBC SSL

We have a remote PostgreSQL DB server which requires SSL certs to be provided to connect to it.
I have the following certs with me.
root.pem
intermediate.pem
private-chain.pem
public-chain.pem
certificate.cer
certificate.key
And I am able to connect to the remote database using psql as
psql "port=5432 host=remote-host user=username sslcert=public-chain.pem sslkey=certificate.key dbname=database sslmode=require"
Now, I need to connect to the same database from a Java Spring based Rest API. So, ideally this would require building keystrokes from the certs and using that to connect to the the db.
The issue is, I'm not able to! I've tried all combinations of cert, public-chain, private-chain, root ca, etc. in the keystore. And I've tried passing the keystore as JVM arguments when calling the jar file (-Djavax.net.ssl.trustStore -Djavax.net.ssl.trustStorePassword -Djavax.net.ssl.keyStore -Djavax.net.ssl.keyStorePassword).
I've also tried pointing to the keystrokes from PostgreSQL JDBC connection string (jdbc:postgresql://remote-host:5432/database?ssl=true&sslcert='filename'&sslkey='key'). Not really sure if this is the right way.
But I keep getting this error.
Caused by: org.postgresql.util.PSQLException: FATAL: connection requires a valid client certificate
at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:473) ~[postgresql-42.2.2.jar!/:42.2.2]
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:205) ~[postgresql-42.2.2.jar!/:42.2.2]
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49) ~[postgresql-42.2.2.jar!/:42.2.2]
at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195) ~[postgresql-42.2.2.jar!/:42.2.2]
at org.postgresql.Driver.makeConnection(Driver.java:452) ~[postgresql-42.2.2.jar!/:42.2.2]
at org.postgresql.Driver.connect(Driver.java:254) ~[postgresql-42.2.2.jar!/:42.2.2]
I am not able to figure out why it works with psql and not with jdbc.
EDIT 1:
Currently I am trying the following approach. This is the spring datasource configuration
spring.datasource.url=jdbc:postgresql://remote-host:5432/database?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
spring.datasource.username=username
This is the cert config
export PGSSLCERT=/tmp/client.cer
export PGSSLKEY=/tmp/client.key
export PGSSLMODE=allow
I've also followed the steps described here to trust root ca. But I guess that is not necessary since I'm using org.postgresql.ssl.NonValidatingFactory
And I'm starting the application as
java -jar -Dspring.profiles.active=prod application.jar
Any insights into this are appreciated! Thanks.

What does your pb_hba.conf setting look like?
The JDBC driver only supports the trust, ident, password, md5, and crypt authentication methods.
So your java app will have to connect using password and certificate. You can specify that in your pb_hba.conf:
hostssl all all 0.0.0.0/0 md5 clientcert=1

Reach HTTPS url using wildcard SSL certificate

My web application is trying to reach the WSDL deployed at another server with the URL: https://172.xx.xx.xxx/interface/Webservice?WSDL
In order to do this, I've installed their SSL certificate to the keystore of my application server. However, the SSL certificate of the server I'm connecting to uses a wildcard SSL certificate.
Thus I'm getting the error: HTTPS hostname wrong: should be <172.xx.xx.xxx>
The server I'm connecting to doesn't have any plans to add my desired SAN in their certificates. Is there another way to connect to a wildcard SSL certificate?

ssl client authentication without ssl re-negotiation

On client side I have Apache HTTP client on jdk5u22. On server side I have tomcat on jdk6u27.
With this setup if I try SSL Client authentication (2 way SSL) then it cause "javax.net.ssl.SSLHandshakeException: Insecure renegotiation is not allowed" on the server and handshake fails. It succeeds if I set system properties sun.security.ssl.allowUnsafeRenegotiation=true and sun.security.ssl.allowLegacyHelloMessages=true on server.
As per the link http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html this is coz JRE6u27 has the RFC 5746 implementation and JRE5u26 below doesnt have this and so both are incompatible. Unfortunately 5u22 is the latest freely available java 5 version. So I want to know if it is possible to have SSL client authentication without ssl re-negotiation.
Regards,
Litty Preeth

As per the redhat site https://access.redhat.com/kb/docs/DOC-20491#Renegotiations_disabled_in_Apache_Tomcat :
Tomcat may ask the client to renegotiate in certain configurations using client certificate authentication, for example, configurations where:
A client certificate is not required on the initial connection, such as when:
1. The clientAuth attribute of the HTTPS connector using JSSE is set to
false. Or The SSLVerifyClient attribute of the HTTPS connector using
OpenSSL is set to none.
AND
2. A web application specifies the CLIENT-CERT authentication method in
the login-config section of the application's web.xml file.
So to avoid re-negotiation in tomcat just make the whole site secure and not just a part of it by setting clientAuth="true" for ssl .
Hope this helps someone.
Regards,
Litty