This has been a problem for myself and my colleagues who have also tried this for quite some time (we keep revisiting the issue to try and fix) whereby the process of getting the packages for a flutter app fails. It works perfectly from my home pc but in work it does not.
Running flutter pub get from my cli returns pub get failed (-10737418819). If I append -v to flutter pub get I get much more information which describes the HTTP get it attempts to make which is:
https://pub.dartlang.org/api/packages/cupertino_icons
with an accept header of 'application/vnd.pub.v2+json'
If I then use a tool such as Postman to send a Http Get with this information, it fails and reports that it could be down to:
Self-signed SSL certificates are being blocked:
Fix this by turning off 'SSL certificate verification' in Settings > General
So I turn this setting off and it works as expected, returning JSON data about the cupertino packages. I think the fix to my problem has something to do with SSL certificate verification but I don't know where to start. Does anyone have any idea?
Generally the Issue is from server side as the Website does not has SSL Certificate and you are trying to access with "https".
use the Same URL we "HTTP" it will work
Related
I´m somehow new in the world of the self signed certs. I´m not sure that using one of this is posible to test my angular front. Looks like in my back all works fine with the same self-signed openssl generated certs.
When I access to https:// the login screen appears as normally but console throw back this error logs:
An SSL certificate error occurred when fetching the script.
Service worker registration failed with: DOMException: Failed to register a ServiceWorker for scope ('https://192.168.154.136/es/') with script ('https://192.168.154.136/es/ngsw-worker.js'): An SSL certificate error occurred when fetching the script.
And when trying to log in with a existent user:
POST https://192.168.154.135:3333/api/login/common net::ERR_CERT_COMMON_NAME_INVALID.
If someone have being in the same type issue or similar, it would be a pleasure to hear about.
I'm using ESP32 Arduino "WiFiClientSecure" client set to client.insecure() to make API calls to my Heroku-hosted app, and after deploying my custom domain I receive the following error.
http://myapp.herokuapp.com/apicall works from browser and from ESP32.
http://api.mydomain.com/apicall works from browser, but fails from ESP32 with error message:
[E][ssl_client.cpp:36] _handle_error(): [start_ssl_client():216]: (-30592) SSL - A fatal alert message was received from our peer
[E][WiFiClientSecure.cpp:133] connect(): start_ssl_client: -30592
Mydomain is set up to Heroku DNS with a C-record.
I don't have a great understanding of SLL. If I can avoid putting a certificate in the ESP32 firmware I'd love to. But I have found myself replacing the ESP32 Arduino code with ESP-IDF code several times, so I'm willing to get rid of Arduino in this case as well if that turns out to be necessary.
I would really appreciate any pointers on where to start the debug. I don't know where to look next.
The whole issue is that I needed a paid subscription to use SSL on a custom domain. This sentence on the Heroku wiki could use some clearer wording: "Apps using free dynos can only use the *.herokuapp.com certificate."
As soon as I signed up for a $7 per month Hobby subscription, everything started working.
I'm kinda at a loss here.
Trying to set up proton with SSL / TLS access, but after creating the certificates with the (modified) shell scripts
supplied by the AppDev-Pack and linking the keyring and everything in notes.ini, I always seem to get
the error "Handshake failed with fatal error SSL_ERROR_SSL: error: 100000f7:SSL routines:OPENSSL_internal:
WRONG_VERSION_NUMBER".
Tried both a windows and linux server, as well as using the accessing node.js app with and without
certificates - but with no success.
Also tried the troubleshoot section of https://doc.cwpcollaboration.com/appdevpack/docs/en/proton-admin.html and it connected just fine,
but won't if i connect with node.js.
Looks like the error is thrown before a certificate is even checked?
In this example the error is thrown after trying to get a document by UNID.
notes.ini (proton parts)
gRPC Client Error
If someone has an idea how to fix that issue or where to start - that would really help me.
Thanks in advance.
It appears that the client side does not have the secure flag set. At least I get a similar stack when I try to connect without TLS when the server expects TLS.
See the secure attribute when calling useServer() function, and you'll also need to provide the credentials attributes.
I have implemented FCM for web using fcm documentation.
Everything'll be fine if I set url like : 'http://xxx' I have no error.
But when I set url : 'https://xxx..', I get error:
"Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script."
code: "messaging/failed-serviceworker-registration"
"Messaging: We are unable to register the default service worker. Failed to register a ServiceWorker: An SSL certificate error occurred when fetching the script. (messaging/failed-serviceworker-registration)."
Can anyone show me how to fix this error?
This is a general problem when wanting to test service workers in a local development environment without proper SSL certificates. It is not specific to Firebase Messaging but pertains to Service Workers in general.
Here is the solution I found when using Google Chrome: Testing Service workers locally with self-signed certificates
Unfortunately, I don't know yet how to circument the issue with other browsers, but probably there must be similar ways.
For Chrome, you need to start a new instance of Chrome, with some flags telling it to ignore SSL certificate errors for your local origin:
In Linux (and maybe Mac):
google-chrome --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://127.0.0.1 --user-data-dir=/tmp/foo
The https://127.0.0.1 here is the location where your app (and service worker) is hosted locally. You might need to adjust this to use the appropriate port, if serving on a different port than the standard HTTPS port 443, e.g. https://127.0.0.1:3000, when serving your app over HTTPS on port 3000.
The --user-data-dir=/tmp/foo is necessary to start a new instance, with a new user profile, if another instance of Chrome is already running.
In Windows (might vary, depending on where your chrome.exe is):
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=https://localhost:1123
Again, you might have to adjust the port.
Easier method that worked for me:
Just paste chrome://flags/#allow-insecure-localhost in your chrome browser, and Enable the setting that says something like "Allow invalid certificates for resources loaded from localhost."
I'm running a site and several sub domains on ColdFuson 10 Standard, we have just upgraded from ColdFusion 9 where everything was working fine.
The sites have a wildcard ssl certificate installed so all the sub domains are secured. I'm making http calls between the sites but getting the I/O Exception: peer not authenticated error.
Charset [empty string]
ErrorDetail I/O Exception: peer not authenticated
Filecontent Connection Failure
Header [empty string]
Mimetype Unable to determine MIME type of file.
Responseheader struct [empty]
Statuscode Connection Failure. Status code unavailable.
Text YES
I've installed the certificate in the correct key store and verified it's there using keytool -listand restarted, but still get the authentication error.
I know this is a common problem and is usually fixed by installing the certificate and there are workarounds for ColdFusion Enterprise but I'm struggling to get this working on Standard. Any suggestions?
After many days of investigation I came across this blog post which leads to bug report #3598342.
It turns out to be an issue on Windows 2012 servers running IIS 8. There is an option on the site binding to 'Require Server Name Indication' or 'SNI'. Turning this option off allows cfhttp to connect via https.
It turns out this is an issue with the HttpClient library and has been fixed in builds 288845, 288846 and 290605. Which doesn't really help as the last update 13 only gives me build 287689.
This could be an issue I have run across where I had to import the secure server certificate into coldfusion before it would allow me to connect.
http://helpx.adobe.com/coldfusion/kb/import-certificates-certificate-stores-coldfusion.html
Import Certificate for ColdFusion10
Hope that helps. I know it helped me!