Service worker SSL certificate problem when trying to deploy my angular+nestjs in my local lab with different vm for front and back - ssl

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.

Related

flutter pub get failed (-10737418819) - self-signed SSL certificates blocked?

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

Configuring Proton for SSL / TLS throwing openssl wrong version number and gRPC client error

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.

CryptographicException exception when setting up SSL handshake with MailKit using .NET Core

What we are trying to do is send an email from a pod (running Linux based on the image "microsoft/dotnet") on a client's Openshift environment using MailKit:
https://github.com/jstedfast/MailKit
We get an exception thrown when trying to set up the SSL Handshake:
MailKit.Security.SslHandshakeException: An error occurred while
attempting to establish an SSL or TLS connection.
System.Security.Cryptography.CryptographicException: Error occurred
during a cryptographic operation
We have tried using the.NET SMTP client as well and it worked (using a secure connection)! Unfortunately this component is now obsolete and Microsoft recommends to use MailKit.
Going through the .NET source code the exception raised is a generic catch all exception which looks like it comes from unexpected code returned from the OpenSSL library. Unfortunately I can't see how to get the error code (it is logged using "Debug.Fail", but I am unable to setup a trace to see it) so I am not sure what it is.
I have written a test just to build the X509Chain. When we have the Revocation Mode set to Online (the default) we get the exception. When the revocation is disabled it seems to build the chain OK.
When I run the test on our Test Openshift environment that is totally independent to the client's we get the following error, but do not see the exception: "unable to get certificate CRL"
The only thing I have noticed about the Revocation List is that there is a LDAP and HTTP URLs. Perhaps there is an issue processing the LDAP URL?
Any help on this would be appreciated!
This is something you should report to github.com/microsoft/dotnet

Bot Emulator V4 connection: request to https://localhost:44378/api/messages failed, reason: unable to verify the first certificate

In the latest Bot Framework Emulator 4.0.0-preview.40025 (although it this has occurred in every version I try), I get the following error:
[11:37:11]Emulator listening on http://localhost:65141
[11:37:11]ngrok not configured (only needed when connecting to remotely hosted bots)
[11:37:11]Connecting to bots hosted remotely
[11:37:11]Edit ngrok settings
[11:37:11]POST201directline.startConversation
[11:37:11]request to https://localhost:44378/api/messages failed, reason: unable to verify the first certificate
[11:37:11]request to https://localhost:44378/api/messages failed, reason: unable to verify the first certificate
The original V3 Bot framework emulator works fine.
Any help appreciated.

SSL error when using https FCM

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."