I am having trouble using Guzzle within a local environment via MAMP.
The site is using SSL.
The error is as seen below:
Uncaught GuzzleHttp\Exception\RequestException: cURL error 77: error setting certificate verify locations: CAfile: /Applications/MAMP/Library/OpenSSL/cert.pem CApath: none (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
I was developing on a Windows machine using XAMPP, and things were working without issue. I was not developing using SSL at that time. I have migrated to a Mac and since have began using MAMP.
Things works as expected when deployed to a true staging server that also uses SSL.
Related
I developed a spring MVC app in eclipse and trying to test in my laptop tomcat localhost. This URL works http://localhost:8080. It brings up the tomcat admin page. But when i call http://localhost:8080/mywebsite, as part of spring security port mapping it forwards to https://localhost:8443/mywebsite, but i get
This site can’t be reached
localhost refused to connect.
Try:
Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED
This is definitely not firewall issue, as i uninstalled all my antivirus, disabled firewall in windows defender
I have also changed the server location to "use tomcat installation" in eclipse
I have cleaned up deployment folder multiple times and reinstalled app and restarted server multiple times. The server started successfully i can see the logs
I am using tomcat 9 and JDK-19
I dont see any calls in access logs, only a 302 when it redirects from http://localhost:8080/mywebsite to https://localhost:8443/mywebsite
I have been trying this for 2 days and it wont budge an inch. I need help please
As #nitin pointed out in the comment above, I had not configured SSL connector. My bad I thought SSl cert is not needed for localhost testing. But it is required. I following the steps in
https://medium.com/beingcoders/setup-ssl-on-apache-tomcat-in-just-10-minutes-step-by-step-guide-706484094bb2
I am using Nginx as a reverse proxy server for MongoDB (deployed in docker) using TCP Streams. Using Nginx also helps me to easily configure SSL certificates obtained from Let's encrypt. Everything is working fine but suddenly I started seeing certificate validation issues across multiple apps when nothing is changed. All my python apps failed by throwing CERTIFICATE_VERIFY_FAILED errors. I can't even connect to the database using the Mongo compass tool via SSL at the same time. MongoDB compass showing as certificate expired. But, I am sure that the certificate is still not expired. I am using the requests 2.3.0 library in python and when I upgrade the requests library the python apps are working but still, the Mongo compass is not connecting. Note that my python apps get/post data to other APIs which are again behind Nginx using SSL certificate issued by Let's encrypt. In python the error occurred whenever it tries to validate the SSL either for db connection or for interesting with other API.
Has any one faced this issue? Can you give any suggestions on the root causes for these errors?
I'm having an issue getting Traefik to proxy applications that are secured using Integrated Windows Authentication (IWA). When the content being served is simply an IIS virtual directory secured with IWA there is no problem. However, when it is a .NET Core application or MVC application or even just a simple Default.aspx page and IWA is enabled I continually get prompted for my credentials (never being accepted). See below for my configuration:
Traefik Configuration:
# ns-ws
[frontends.ns_ws]
passHostHeader=true
entrypoints=["http","https"]
backend = "ns_ws"
[frontends.ns_ws.routes.match_all]
rule = "Host:ns-ws.example.com"
[backends.ns_ws]
# ns-ws
[backends.ns_ws.loadbalancer.stickiness]
[backends.ns_ws.servers.server1]
url = "http://x.x.x.x:80"
I've played with removing pass host headers and stickiness, but no luck.
Seems like the original request makes it through because I do not get an unauthenticated error message from IIS for the page, but most subsequent requests to the server will return a 401 (seems sporadic).
Example Image:
I've tried changing the "authPersistNonNTLM" option in IIS, as described here: https://boyan.io/kerberos-load-balancers/ (with no luck)
I realize this is a very stale issue but in case this helps others.
I can confirm that Windows Integrated authentication works successfully with Traefik 2.x using a TCP as opposed to HTTP router with successful logins proven on Windows/Mac using Safari/Chrome/IE.
Note that when testing it is important to ensure you have cleared cookie caches or you can get unpredictable results due to prior login attempts on non-working configurations you may have attempted. Indeed I experienced something similar to your described behavior with repeated unexplained login prompts until I reset my browser.
In our configuration we have a mixed-OS docker Swarm (Linux/Windows) with Traefik operating on Linux and sending requests straight to back-end Windows-containers running on Windows swarm nodes.
If you have configured your Windows app and containers correctly I can confirm that from:
A domain-joined machine you will get straight through login to Windows back-end containers using the domain-joined machine's Kerberos credentials
A non-domain-joined machine connection will downgrade to Windows NTLM authentication and prompt for Windows authentication credentials.
From a Traefik configuration perspective our docker containers have labels like this:
- "traefik.tcp.routers.dotnet-tcpexample.entrypoints=websecure"
- "traefik.tcp.routers.dotnet-tcpexample.tls=true"
- "traefik.tcp.routers.dotnet-tcpexample.tls.options=default"
- "traefik.tcp.routers.dotnet-tcpexample.rule=HostSNI(`windows.foo.bar`)"
- "traefik.tcp.routers.dotnet-tcpexample.tls.passthrough=true"
- "traefik.tcp.routers.dotnet-tcpexample.service=dotnet-tcpexample"
- "traefik.tcp.services.dotnet-tcpexample.loadbalancer.server.port=443"
Note that configuring containers for Windows integrated authentication in itself is non-trivial but documented here.
we have set up a CalDAV server here with SOGo as backend and frontend (WEBUI). Which is working as expected.
But there are some errors which I cannot reproduce and the logging also gives no hint since there is no logging:
1) macOS 10.11 - latest release
I can login to CalDAV, I can create entries (which are synced) and they show up in WEBUI. But events created in WEBUI are not synced.
2) Same credentials, same usage on iPhone iOS12 - I can't even log in to the calender.
Here the HTTP error in the log indicates a "Forbidden"...but as stated the credentials are correct - maybe iOS sends a authentication methode which is not installed on my server?
Dan
The answer to this question is very simple and seems intuitive:
Install SSL certificate for https connections to SOGo web-root
Forward all http requests to https
I'm using the IdentityServer3 Version (2.5.4) for the current project, everything works fine on my local machine (with IIS and IIS Express).
The customer has a Windows7 Embedded machine (without SP1!) with .NET 4.5 installed, we created a selfsigned SSL cert (with the current hostname, NOT localhost), but its not working. I'm always getting the error "Unable to get document from: https://xyz/.well-known/openid-configuration"
what is wrong with the configuration?
I found the Solution, it has nothing to do with the Configuration. The Installation of the Windows 7 SP1 has fixed it.
In a couple of cases where we had this issue, it is mostly to do with network connectivity.
Few things which helped us figure out the root cause -
Access the "https://xyz/.well-known/openid-configuration" route from a browser on the server.
If you are not able to access the url then it means that the server is unable to connect to the Idserver installation. This is a network level issue.
If you are able to access the url from the server where the relying application is hosted, but the relying application is throwing an error -> it means that, a proxy is configured on the server. The browser automatically uses the proxy, where as you have to set the proxy in the relying party application as below in the startup.cs
var request = WebRequest.Create(uri);
var myProxy = new WebProxy {Address = new Uri("proxy uri")};
request.Proxy = myProxy;
var response = request.GetResponse();
This will ensure that all the http requests originating from the code will also use the same proxy.
If the above doesnt help, Check if the IIS where Idserver is installed, allows TLS 1.0 and 1.1. THis is disabled on some servers for security purposes. If that is the case, use the below code to make ur application use tls 1.2 and the call will succeed
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;