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
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 having problems enabling TLS in Elasticsearch 7.1.1 running on Windows 7.
I have a single node with certificates created as
elasticsearch-certutil ca
elasticsearch-certutil cert --ca elastic-stack-ca.p12
The elasticsearch.yml file has the following settings
node.name: node1
discovery.type: single-node
xpack.security.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
xpack.security.transport.ssl.truststore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
This works fine but when I add the below
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
xpack.security.http.ssl.truststore.path: 'C:\elasticsearch-7.1.1\config\certs\elastic-certificates.p12'
and start up elasticsearch I see the following error
[2019-06-25T07:34:19,659][WARN ][o.e.h.AbstractHttpServerTransport]
[node1] caught exception while handling client http traffic, closing
connection Netty4HttpChannel{localAddress=0.0.0.0/0.0.0.0:9200,
remoteAddress=/127.0.0.1:6757}
io.netty.handler.codec.DecoderException:
io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record:
This is repeated every 10-15 seconds.
https is enabled though and I can access the node using https://localhost:9200
I don't know why I receive the above error though as nothing else is running and accessing elasticsearch.
Any help would be much appreciated.
Thanks heaps
It was pointed out to me, on the elastic forum, that the above is a warning and not an error. I still couldn't understand what was causing it as I wasn't running any service or anything else that could be causing it but eventually found something called heartbeat that was running. This was obviously setup in an earlier version/previous installation of Kibana and this was still running, making a call using http and thus causing the above error (this is used for creating dummy data to use for/by to demo Kibana).
I came across this problem too. And IF you have previously installed Elastic Search then high chance you got some residual indices with "red" status, which makes the process of enabling TLS unsuccessful.
Try this command to verify your indices and their statuses
curl -XGET https://localhost:9200/_cat/indices
then delete those with red status.
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.
My app just got ready for sale on App Store, but none of my production devices (devices that have installed the app from App Store) are getting push notifications. When I try to send a push notification to a production device, I am getting this error:
"The credentials supplied to the package were not recognized"
(System.ComponentModel.Win32Exception)
This exception is internally thrown and caught in an infinite loop:
It is thrown at line 539 of ApplePushChannel.cs file:
try
{
stream.AuthenticateAsClient(this.appleSettings.Host, this.certificates,
System.Security.Authentication.SslProtocols.Ssl3, false);
//stream.AuthenticateAsClient(this.appleSettings.Host);
}
catch (System.Security.Authentication.AuthenticationException ex)
{
throw new ConnectionFailureException("SSL Stream Failed to Authenticate as Client", ex);
}
This is the output of the application in Visual Studio Output:
...
A first chance exception of type 'System.ComponentModel.Win32Exception' occurred in System.dll
A first chance exception of type 'System.ObjectDisposedException' occurred in System.dll
A first chance exception of type 'System.ComponentModel.Win32Exception' occurred in System.dll
A first chance exception of type 'System.ObjectDisposedException' occurred in System.dll
A first chance exception of type 'System.ComponentModel.Win32Exception' occurred in System.dll
A first chance exception of type 'System.ObjectDisposedException' occurred in System.dll
A first chance exception of type 'System.ComponentModel.Win32Exception' occurred in System.dll
A first chance exception of type 'System.ObjectDisposedException' occurred in System.dll
A first chance exception of type 'System.ComponentModel.Win32Exception' occurred in System.dll
...(it keeps getting thrown until I stop it manually)
Here are the things I've tried:
Double checked that the device ID I'm trying is registered with a production device token.
Revoked and regenerated the APNS Production certificate, exported it with the private key to a new .p12 file, and tried again with the new certificate. (I had the same problem with development push notifications, and this solved my problem)
Changed the SSL protocol from Ssl3 to Tls. (a few days ago there was a problem with protocol version, and it fixed a problem temporarily. There shouldn't be need for this, but the error I'm getting is the same as the one I was getting before which this fixed)
Checked that I'm actually trying to connect to production server with the production certificate instead of development server/certificate.
Checked that I can access the APNS server directly (my ASP.NET app lives inside a Parallels VM Windows 8.1 at my Mac, here is the output from my Mac, just to avoid confusion:
(Terminal output)
Edit: I was pinging the sandbox server, I've pinged the production server, I verify that I can connect to it too, so it's not the issue.
can$ sudo nmap -p 2195 gateway.sandbox.push.apple.com
Starting Nmap 6.40-2 ( http://nmap.org ) at 2014-04-28 00:06 EEST
Nmap scan report for gateway.sandbox.push.apple.com (17.149.34.189)
Host is up (0.49s latency).
Other addresses for gateway.sandbox.push.apple.com (not scanned): 17.149.34.187 17.149.34.188
PORT STATE SERVICE
2195/tcp open unknown
Why would PushSharp not negotiate with APNS servers?
I figured out the problem. I revoked and regenerated the certificate again, and this time I only exported the private key (without the certificate). In Keychain access, I exported as .p12 and used the new file and it worked. For some reason, PushSharp wasn't play well with .p12 when both certificate and private key are present in the file.
"The credentials supplied to the package were not recognized" exception usually indicates that the user running the code does not having enough permissions.
If you are sending push notifications from Azure web app or webjob do not load the APNS certificate from a file or base64-encoded string. Go to Azure Portal and add the certificate to website instead. Note the thumbprint.
Next add WEBSITE_LOAD_CERTIFICATES setting and set it to * (asterisk).
Now the APNS certificate can be used from C# code:
string thumbprint = "YOUR THUMBPRINT";
var store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
var certificate = store.Certificates.Find(
X509FindType.FindByThumbprint, thumbprint, validOnly: false)
.Cast<X509Certificate2>().SingleOrDefault();
var apnsConfig = new ApnsConfiguration(
ApnsConfiguration.ApnsServerEnvironment.Production, certificate);
References
Using Certificates in Azure Websites Applications
Configuring a certificate for APNS on the Azure platform
When using the windows certificate store, (imho the easiest way to manage certificates on a production server), be sure to set the correct permissions on the private key.
None of the answers worked for me. In the end what I ended up doing is importing the Cert and Private Key into the Windows cert store, and then exporting as a .pfx.
I was tested it again and again.
Convert the p12 file to pem format, and it will work with IIS limited users and maybe with Azure....
I was receiving the same exception and in my case I had to add permission for my IOS Push Services certificate.
Right click on the certificate in mmc -> All Tasks -> Manage Private Keys...
I added NETWORK SERVICE because the iis application pool of my web app used that account.
See for more details: http://blog.falafel.com/apple-push-notifications-certificates-and-iis/
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server