I'm currently working on a project that requires connecting to oracle eventhub which is a Oracle's version of kafka. The systems contacting the restproxy wouldnt accept the self signed certificate hence i'm trying to do either :
1- turn off https and allow for http connections to kafka
2- import a signed certificate i generated
unfortunately i cant locate the certificate store neither do i know how to or even if it is possible to have the rest proxy run on http
The solution was more simple than i thought, obviously Oracle Eventhub rest-proxy uses nginx for service exposure, few modifications to the configuration file and i was able to both remove https and allow for a certificate that i had issued
Related
I have a Service which is running in Istio 1.16 with envoy sidecar injection enabled.
The service connect with a remote API every now and then to send the health information.
The remote end point is https but without having a domain name, yeah the endpoint have to be invoked like https://168.x.x.x/http/health. I could see the connection is working fine with another API but with a proper hostname.
So the issue is clearly with the DNS resolution, I am not great with networking. So, you folks should help me out.
This is the error i get from the server (of service).
x509: cannot validate certificate for because it doesn't contain any IP SANs
Istio version - 1.16
Kubernetes - 1.24
golang (service) - 1.19
Can we bypass this x509 SAN check using destination Rules?
The error "x509: certificate has expired or is not yet valid" usually occurs when the SSL certificate being used has expired or has not yet been activated. This error can also occur when the certificate being used is not valid for the domain or IP address that the request is being sent to.
To resolve this issue, you will need to either obtain a new valid SSL certificate or renew the existing certificate.
You can check your certificate expiration date by using the below command:
kubeadm certs check-expiration
Refer to this SO for more detailed steps.
Short story
I'm trying to send a POST request from a PL/SQL script using the utl_http utility in Oracle. I've been able to send the request using http, but not https. I've added what I thought was the necessary certificates to a Oracle Wallet, and I believe they are being imported and used (but in all honesty, this is a little hard to verify). My current assumption is that calls from our DB server are passing through a proxy server, and that that is somehow messing up some part of the https / certificate functionality.
Supporting evidence (possibly?): I tried to make calls (POST requests) to a dummy service at webhook.site. Again, I got this working with http, but not https - the latter results in a cert validation error.
I then tried to replicate the behavior using postman, and that basically produces the same result, unless I fiddle around with the settings:
Initial Postman result:
Could not get any response
There was an error connecting to https://webhook.site/950...
Disabling SSL verification
Under the Post man settings, I turned off SSL Certificate Verification, and tried again. This time, I got a 200 OK response, and confirmed that the webhook received the post request fine.
It seems clear that the error is due to a missing cert, but I can't figure out which, or how to configure it. My assumption is that if I can get this to work for a webhook-url from Postman (without disabling cert verification), then I should also be able to get it to work from PL/SQL later.
When I look at the webhook site in a browser and inspect the certs, the webhook cert is the lowest cert (leaf node?). Above it there is one intermediate cert related to the company I'm working for, and then a root cert also related to the company. The root node is named something like "Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here.
I've tried downloading all of these certs and importing them into my cert store, as well as importing them under the Postman settings (under Certificates) in various combinations, but nothing seems to make any difference; all attempts at posting with HTTPS produces the following error in my Postman Console:
POST https://webhook.site/9505...
Error: unable to verify the first certificate
Any ideas about how to resolve this, or at least obtain more information about what to do would be greatly appreciated.
Switching OFF "SSL Certificate Verification" in Postman only means that it (i.e. Postman) will not check the validity of SSL certificates while making a request. Meaning that it will just send the certificates as they are. Because your connection fails if the setting in ON, this means Postman cannot verify the validity of your certificates.
This is most likely the case with the actual service you're trying to POST to, they cannot verify the certificates. Is that service outside your company network? And is it a public one or one owned by your company? Where is that service hosted? What certificate do they need?
BTW, TLS client certificates are sent as part of establishing the SSL connection, not as part of the HTTP request. The TLS handshake (and exchange/validation of client and server certificates) happens before any HTTP message is sent.
I'm thinking this might be a blocked port issue.
You said... ""Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here."
That means your client software needs your Company Proxy Server CA in its trusted certificates list. If that client's list is that of the oracle wallet...
https://knowledge.digicert.com/solution/SO979.html
This talks about how to do that.
Also, if your system running postman has a non-oracle based wallet trusted certificate (probably the operating system?) you'll have to execute something like adding the trust to your account on the workstation
https://www.thewindowsclub.com/manage-trusted-root-certificates-windows
in order to have the proxy server certificate trusted.
Once the certificate you're making the connection with has a root of trust per the effective configuration of the client being used, then you'll be able to verify the certificate.
A couple of possible issues:
The server doesn't actually support HTTPS. Connect a browser to the URL that you POST to, and see if you receive a response. (It looks like you already did this, but I'm documenting it for completeness.)
The server uses the Server Name Indication (SNI) extension to determine what certificate chain to send back, but your POSTing client doesn't send that extension. You can identify this case by looking up the IP for the host you're POSTing to, then going to https://nnn.nnn.nnn.nnn/ (obviously use the IP here, instead of the literal string 'nnn.nnn.nnn.nnn') in your browser, and checking the certificate chain it returns. If it is not the same as you get from step 1, this is your problem, and you need to figure out how to either get SNI support in your Oracle PL/SQL client or get the POST endpoint exposed on that hostname. (alternatively, you might be able to use these certificates to prime your Oracle Wallet, but they might have an issue with the hostname in the certificate not matching the hostname you connect to.)
You have a proxy in the way. I don't think this is what's going on, since that would basically only cause problems if you were doing client-side certificate authentication. (If this is the problem or is a condition, you need to import those certificates into your trusted wallet; you also need to ensure that the server you're posting from is going through the same proxy. Otherwise, you need to ensure that the certificate authority for the proxy that the machine actually running the code sees is in the wallet. This may require the assistance of the system/network administrators who run that machine and its connection to the network.)
HTTPS is a finicky beast. Many, many things must work exactly correctly for TLS connections to work and the certificates to correctly verify (the TLS port must respond, the client and server must agree to speak the same version of TLS, the client and server must agree to use the same cipher combination, the certificate chain presented by the server must be issued by a CA the client recognizes, and the leaf certificate in that chain must certify the name client requested).
SNI is needed to support multiple names on a single host without messing with the certifications of other names on the same host. Unfortunately, SNI is one of those things that has been standardized for over a decade (RFC 3546), but many enterprise-grade softwares haven't implemented.
I have been working with web services connecting to URLs provided by different clients and so far it has all been done using one-way authentication. Now I'm asked to enable 2-way (mutual) authentication for one of the clients. I did a lot of research and reading but still confused about a lot of things.
I could test successfully on my local machine following instructions from various different articles. But the problem is now to deploy it in production.
Here's what I did for testing: I created a test Web service Host and assigned it a self-signed certificate and created a client to test this. After this I created a client certificate using makecert and verified that this is installed via MMC. I then modified my Host app to only allow clients with certificate and tested from client to see the connection refused due to not providing the client certificate. Then I modified the bindings in the client application to include the certificate name and I was able to connect to the Host successfully. So this completes local hosting.
Now the real problem. The tech team is going to create a certificate in "cert store" on the server. And I need to test again to make sure everything works as expected. We have a few different developers who all want to test on their machines on their local code. Can we all use the same certificate somehow? I don't think we would be allowed to import the certificate but what suggestions could I give them so all of us can use the same certificate?
I'm also confused about issues like difference between windows certificate and IIS certificate. What advantages would the IIS certificate provide?
Thanks for help!
Edit: Could one of the differences between installing on IIS be so that the hosted sites be accessed via SSL connection? This would mean we don't really need to install on IIS if it's just a client certificate. Is this correct?
I am using Spring3, Hibernate4 and postgres9.2.
For enabling the SSL database connection, I followed following steps :
Creating self signed Certificate : refer : http://www.postgresql.org/docs/9.2/static/ssl-tcp.html#SSL-CERTIFICATE-CREATION
Copied the generated server.crt and server.key into postgres/9.2/data folder.
URL for hibernate connection : jdbc:postgresql://localhost:5432/DB_NAME?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
After restarting the postgres I run my application and it gives error as :
org.postgresql.util.PSQLException: The server does not support SSL.
at org.postgresql.core.v3.ConnectionFactoryImpl.enableSSL(ConnectionFactoryImpl.java:307)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:105)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:65)
at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:140)
at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:29)
at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:21)
at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:31)
at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:23)
at org.postgresql.Driver.makeConnection(Driver.java:393)
at org.postgresql.Driver.connect(Driver.java:267)
Even I tried to add this line at the end of pg_hba.conf file but postgres does not get restarted :
hostssl all all 127.0.0.1/32 trust
EDIT
It is for other folks who received such error or wants to add database ssl connection :
I added ssl = true and removed comments for ssl related entries from postgresql.conf and it worked. :)
The root of your problem appears to be that your server does not support SSL or does not have it enabled. The message:
The server does not support SSL
may only be emitted by org/postgresql/core/v3/ConnectionFactoryImpl.java in enableSSL(...) when the server refuses or doesn't understand SSL requests.
Sure enough, in your update you say that you had the SSL-related options in postgresql.conf commented out. Them being commented out is the same as them being not there at all to the server; it will ignore them. This will cause the server to say it doesn't support SSL and refuse SSL connections because it doesn't know what server certificate to send. PgJDBC will report the error above when this happens.
When you un-commented the SSL options in postgresql.conf and re-started the server it started working.
You were probably confused by the fact that:
&ssl
&ssl=true
&ssl=false
all do the same thing: they enable SSL. Yes, that's kind of crazy. It's like that for historical reasons that we're stuck with, but it's clearly documented in the JDBC driver parameter reference:
ssl
Connect using SSL. The driver must have been compiled with SSL
support. This property does not need a value associated with it. The
mere presence of it specifies a SSL connection. However, for
compatibility with future versions, the value "true" is preferred. For
more information see Chapter 4, Using SSL.
As you can see, you should still write ssl=true since this may change in future.
Reading the server configuration and client configuration sections of the manual will help you with setting up the certificates and installing the certificate in your local certificate list so you don't have to disable certificate trust checking.
For anyone else with this problem: There will be more details in your PostgreSQL error logs, but my guess is your PostgreSQL config isn't right or you're using a hand-compiled PostgreSQL and you didn't compile it with SSL support.
If you are using a self-signed certificate you need to add it to your trusted key store of your Java installation on the client side.
You find the detailed instructions to achieve this here: telling java to accept self-signed ssl certificate
In your connection string, try
?sslmode=require
instead of
?ssl=true
Use param sslmode=disable. Work for me. Postgresql 9.5 with jdbc driver SlickPostgresDriver.
I am trying to setup a proxy configuration on a dev 853 domino server, so I can connect to a dev connections server from an XPage (using java).
It's an SSO environment, and both the domino server and connections server are protected by WebSEAL. I want to make server-side calls in java (using the Apache HTTP Client), so my XPages application can make a call across to the Connections server.
I followed some information I found in Niklas Heidloff's Social Enabler documentation: http://www.openntf.org/Projects/pmt.nsf/DA2F4D351A9F15B28625792D002D1F18/%24file/SocialEnabler111006.pdf
and also in here:
http://www.ibm.com/developerworks/lotus/library/inotes-full/index.html
I setup the proxy like this:
Context: /xsp/proxy/BasicProxy/
URL: https://connectionsserver.acompany.com
Actions: GET,HEAD,POST,DELETE,PUT
Cookies: -List of cookies-
Mime-types: *
Headers: User-Agent,Accept*,Content*,Authorization*,Set-Cookie
When I try the call, it gives me the following error:
2/28/13 12:34 PM: Exception Thrown
javax.servlet.ServletException: com.ibm.jsse2.util.g: No trusted certificate found
at com.ibm.domino.servlets.proxy.BasicProxy.throwServletException(BasicProxy.java:765)
at com.ibm.domino.servlets.proxy.BasicProxy.service(BasicProxy.java:357)..
...
Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: No trusted certificate found
I thought that passing the cookies across in this way should work (the cookies should work between both the domino-webseal and connections-webseal environments).
The error suggests that I need to import a certificate. I don't have access to the domino server to allow me to import certificates, so before I request that, I wanted to check I wasn't missing something from somewhere else.
Is there something else I am missing? Or any suggestions on doing this a different way?
Thanks,
Pam.
You have to import the certificates if they are not present. That is what the error message is indicating. There is IBM Technote 21588966 describing the necessary steps.
Furthermore (that could become the next showstopper after you sorted out SSL) you have to have a hard look how WebSeal is configured. The challenge here: WebSeal is designed to accommodate any possible backends and it is easy to get it almost working - almost as in: works for direct access via browser but fails on server-2-server or Ajax etc. The super-highly-recommended-ignore-on-your-own-risk setting for Connections/Domino is to use WebSeal's LTPA capabilities and not some ludicrous code injection.
Hth