I encountered a problem with TSL/SSL configuration. Everything is configured like in the documentation https://cloud.spring.io/spring-cloud-gateway/multi/multi__tls_ssl.html
server:
port: 8080
ssl:
enabled: true
key-password: password
key-store-password: password
key-store: certificate.p12
key-store-type: PKCS12
spring:
cloud:
gateway:
httpclient:
ssl:
trustedX509Certificates:
- someCert.pem
With this configuration it's impossible to call endpoint with http://localhost:8080/home - and this is a desired behaviour.
Despite the configuration I can call all endpoints like https:localhost:8080/home without applying proper certificate. In chrome I can just click 'proceed anyway' and I get the content of endpoint.
I dont want to allow this - if you want to call endpoint from external world you need to have the client certificate. This is my goal but I am missing something.
How to achieve this using spring cloud gateway?
I realize this is old, but in case anyone else comes across it, you were missing a property:
server:
ssl:
client-auth: need
This will force the server to require a Client Certificate before it will accept connections.
Related
I have setup a CAS server at 172.16.238.10 that generally works with the CAS protocol. However, for OAuth2 there is a strange redirection behavior:
REQ: https://172.16.238.10:8443/ooscas/oauth2.0/authorize
RESP: 302, Location: https://localhost:8443/ooscas/login?service=https%3A%2F%2Flocalhost%3A8443%2Fooscas%2Foauth2.0%2FcallbackAuthorize%3Fclient_name%3DCasOAuthClient
Never mind the service and client_name parameters for this staged example, but my question is about the hostname:
Where does the "localhost" come from? How can I configure that to be something else?
In a real OAuth2 webflow localhost will simply not work, even if 172.16.238.10 happens to be localhost. The reason is that by posting the login form to localhost, the CAS server then redirects to itself using localhost (https://localhost:8443/oauth2.0/callbackAuthorize) and that will lead to an internal SSL handshake error, because the server's certificate is not valid for localhost.
Most likely, you need to define the following:
cas.server.name=
cas.server.prefix=${cas.server.name}/cas
You're referencing the prefix in your setup, but its definition seems absent. If you fail to do that, default values take place.
PS Always specify the CAS version in your posts.
In the past I've used ngrok to test twilio webhooks on my local machine - it's always worked. I'm working on a new app that uses Co-Pilot (not sure if it has anything to do with co-pilot) and I'm getting the 11210 error: HTTP bad host name.
I initialize my tunnel with /Applications/ngrok http -host-header=rewrite local.whicheversiteimworkingon.com:80
The URL listed in the Message Text is http://fcd0ed57.ngrok.io/sms/twilio/incoming but the body shows
Twilio was unable to fetch content from: https://local.thesiteimworkingon.com/sms/twilio/incoming
Error: Unknown host local.thesiteimworkingon.com
Account SID: AC5a22f090b458f6942da879d347451dfd
SID: SM9c45741b5b70967df6a7e196e3bee552
Request ID: 9fde222c-14e1-448e-ad79-4a392d212ffd
Remote Host: local.thesiteimworkingon.com
Request Method: POST
Request URI: https://local.thesiteimworkingon.com/sms/twilio/incoming
SSL Version: TLSv1.2
URL Fragment: true
Unfortunately I don't have an example of this from when it was working - it's been months (maybe 12+) since I've had to do this.
[Update] I've confirmed this happens with co-pilot and regular numbers, starting to think it's environment related.
Have I misconfigured something in order to test this locally?
Can you try the https ngrok instead of http?
Twilio developer evangelist here.
It may be to do with the application server you are using expecting a different host name. When you start Ngrok, you can pass the --host-header flag to rewrite the host header for your application.
ngrok http 3000 --host-header=rewrite local.domain.com
Let me know if that helps at all.
I have setup FTP server and enabled TLS/SSL to the server following this tutorial. Once the setup was done, I tried to connect to it from FileZilla and it worked. Now I want to do the same with my rails application.
I came across similar questions and there were some solutions. But all the solutions suggested ignoring the verification as:
OpenSSL::SSL::VERIFY_NONE
But this beats the purpose of having FTP server with TLS enabled.
I came across an article that suggested setting ssl: true like:
ftps = Net::FTP.new(
host,
ssl: true,
username: username,
password: password
)
However, this did not work. I get
SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate)
I found some references about the parameters but am confused about how to use them.
You have a server with a self signed certificate, SSL will fail to verify that always. Right now you have three ways to solve that:
Change your code so it accepts self signed certificates (you already stated this won't work for you).
Request a valid certificate (Letsencrypt seems like a good option).
Use mkcert to create "valid" certificates for development.
If your FTP server is a public server, you should go with #2. #3 is a big help if you're just doing some experiments or setting a local development server.
Jhipster registry:v3.3.0
Keycloak: 4.5.0.Final (https enabled)
There is a jhipster registry setup using docker-compose as shown in picture. Registry talks to Keycloak for authentication.
We have two keycloak instances.
When configured with one keycloak instance it successfully logins and opens the registry page.
When configured with other keycloak instance it show the following page:
After entering keycloak credentials, the url in the browser is http://localhost:8761/login?state=Swy20H&session_state=c6853b18-42f3-4ad9-9ad0-14615aa576bd&code=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..xtptsARyYJPbqrhZD4ZF7A.yKur_w3c5H-ybHcpXeBSca1W7N3XxRzQXaUs383Kqh57wzaWt3FhBglGf-w154GRTM93F5oa2grE8HzVyrRpDadQs5FCjpNDZuD86KZy5JVI4RnlYOFvsTMcO-fFi_bWl2ByvNy7QARglrwGQOTeYndvrYluuC57OJGKm8819gIb9a5wvZ9oeiJLuDPwkcefs2J-xnUvEde3yAyVKGxe_oGdA8jJbbwRDQQvCI2e3FLyiKJ1F2P2iHFT5g_QaQxv.7k__JisYiWQrQpjgxJ8m5Q
Same keycloak client was imported in Keycloak realm for instances. Any idea what could be the reason?
I had faced similar issue.
In my case I was getting it because of two reasons.
The keycloak was SSL enabled and the keystore file used in this
process did not include Root certificate. Refer this SOS.
Our network firewall was blocking the requests to Auth Server. In your case it could be Jhipster registry's backend
you must change configuration in docker file inside your server if you use docker and when enable SSL you must mapping new URI in each docker file
i have the same problem and this is solution for that
- SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OIDC_ISSUER_URI=http://127.0.0.1/auth/realms/jhipster
but after enable ssl your service cannot show above url you must be change it to
- SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OIDC_ISSUER_URI=https://your-domain.eg/auth/realms/jhipster
after that you can authentication without any problem
Dropbox requires the callback URL to be over HTTPS (when not using localhost).
Using Mule 3.6.0 with the latest dropbox connector, the callback defaults to http - thus only working with localhost. For production I need to use https for the OAuth dance.
What is the correct way to specify a https callback URL?
I've tried:
<https:connector name="connector.http.mule.default">
<https:tls-key-store path="${ssl.certfile}" keyPassword="${ssl.keyPass}" storePassword="${ssl.storePass}"/>
</https:connector>
<dropbox:config name="Dropbox" appKey="${dropbox.appKey}" appSecret="${dropbox.appSecret}" doc:name="Dropbox">
<dropbox:oauth-callback-config domain="production.mydomain.com" path="callback" />
</dropbox:config>
But it errors:
Endpoint scheme must be compatible with the connector scheme. Connector is: "https", endpoint is "http://production.mydomain.com:8052/callback"
Here's what I ended up with that solved the problem:
<https:connector name="connector.http.mule.default" doc:name="HTTP-HTTPS">
<https:tls-key-store path="${ssl.certfile}" keyPassword="${ssl.keyPass}" storePassword="${ssl.storePass}"/>
</https:connector>
<dropbox:config name="Dropbox" appKey="${dropbox.appKey}" appSecret="${dropbox.appSecret}" doc:name="Dropbox">
<dropbox:oauth-callback-config domain="myserver.domain.com" path="callback" connector-ref="connector.http.mule.default" localPort="8052" remotePort="8052"/>
</dropbox:config>
This works great for localhost, but not if you need the callback to go to something other than localhost (e.g. myserver.domain.com)
Reviewing mule.log you can see that the connector binds to localhost (127.0.0.0) despite the config pointing to:
domain="myserver.domain.com"
Log Entry:
INFO ... Attempting to register service with name: Mule.Ops:type=Endpoint,service="DynamicFlow-https://localhost:8052/callback",connector=connector.http.mule.default,name="endpoint.https.localhost.8052.callback"
INFO ... Registered Endpoint Service with name: Mule.Ops:type=Endpoint,service="DynamicFlow-https://localhost:8052/callback",connector=connector.http.mule.default,name="endpoint.https.localhost.8052.callback"
INFO ... Registered Connector Service with name Mule.Ops:type=Connector,name="connector.http.mule.default.1"
The workaround is to force Mule to listen to 0.0.0.0 for connectors which define localhost as the endpoint.
In wrapper.conf set
wrapper.java.additional.x=-Dmule.tcp.bindlocalhosttoalllocalinterfaces=TRUE