# NetTalk and SSL **URL:** \ **Category:** questions\ **Tags:** nettalk, ssl\ **Created:** [July 5, 2024, 12:37pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297 "2024-07-05T12:37:31Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![blue](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/3bc359/32.png) [@blue](https://clarionhub.com/u/blue)\ **Post date:** [July 5, 2024, 12:37pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/1 "2024-07-05T12:37:31Z")
Hello everyone, Does anybody uses NetTalk and SSL certificate generated within NetTalk itself? I get message in Firefox: > ...Cannot communicate securely with peer: no common encryption algorithm(s). > > Error code: SSL\_ERROR\_NO\_CYPHER\_OVERLAP And in Edge: > ERR\_SSL\_VERSION\_OR\_CIPHER\_MISMATCH All fields have necessary data, as written in help. OpenSSL can be started on server. DNS is updated to correct IP address. NetTalk version is 12.63. Server version is Windows 2022. When I double click on CSR file for domain I get this message: ![image](https://clarionhub.com/images/transparent.png) I do not know is this desired behavior? ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [July 5, 2024, 6:39pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/2 "2024-07-05T18:39:39Z")
I would not describe that as desirable behavior. How did uou generate the certificate? ---
**Author:** ![blue](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/3bc359/32.png) [@blue](https://clarionhub.com/u/blue)\ **Post date:** [July 6, 2024, 10:21am UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/3 "2024-07-06T10:21:58Z")
I upgraded to version 14 and that helped, since it has a more log data. Server is on AWS, and only ports allowed from the internet to the server are 80 and 443, when certificate creation is started connection is blocked. When I allowed all traffic in ACL, the test certificate was created correctly. This is a little problem, Let’s Encrypt does not publish it’s IP range, and addresses are changed… ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [July 6, 2024, 7:34pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/4 "2024-07-06T19:34:59Z")
The LetsEncrypt protocol only uses port 80 for incoming. But most of the conversation happens with the server making an outgoing connection to LE. Im not sure how the IP address comes into play, umless you are blocking outgoing connections to remote port 443. ---
**Author:** ![blue](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/3bc359/32.png) [@blue](https://clarionhub.com/u/blue)\ **Post date:** [July 8, 2024, 9:06am UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/5 "2024-07-08T09:06:40Z")
It seems to be that the other ports are used for incoming connection. When ACL in AWS is set like this: ![image](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/4/4ce3b56568dc8f3128f01369e204809a2a692740.png) The message in NetTalk is: > [7/08/24-10:47:56] -53 The requested connection to [acme-staging-v02.api.letsencrypt.org](http://acme-staging-v02.api.letsencrypt.org) could not be opened. The Open command timed out or failed to connect And when I try to open URL, the message is: ![image](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/6/6a4f01d60287be9db907dcfb0cbd8b8317d46054.png) When I change the rule no. 130 to allow: ![image](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/a/a49c73bb98998deb4fc0748ffaf1aca02da084cc.png) And generate certificate, then it is desired behavior for test certificate when I try to open the domain. Message is: ![image](https://clarionhub-uploads.s3.eu-north-1.amazonaws.com/original/2X/c/c8993fd1233aa0ed27cd02321282f27bd379d0af.png) ---
**Author:** ![elliteharry](https://clarionhub.com/letter_avatar_proxy/v4/letter/e/46a35a/32.png) [@elliteharry](https://clarionhub.com/u/elliteharry)\ **Post date:** [September 5, 2025, 9:18am UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/6 "2025-09-05T09:18:00Z")
I’ve seen the same issue when using NetTalk with its own generated SSL certificate. The browser errors like SSL\_ERROR\_NO\_CYPHER\_OVERLAP in Firefox or ERR\_SSL\_VERSION\_OR\_CIPHER\_MISMATCH in Edge usually mean the server and browser can’t agree on a TLS version or cipher. By default, modern browsers only allow TLS 1.2+ with strong ciphers, while NetTalk’s built-in SSL might be using older ones. A good fix is to use a certificate generated with OpenSSL or from a trusted CA and make sure TLS 1.2 is enabled in NetTalk. That solved the mismatch problem for me. You can find the error solution at:- CheapSSLWEB. com ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [September 6, 2025, 5:11am UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/7 "2025-09-06T05:11:39Z")
Just FYI ‐ the default for NT14 is TLS 1.3, dropping to TLS 1.2 if the client doesnt support 1.3. By default it wont drop below 1.2. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [September 6, 2025, 5:13am UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/8 "2025-09-06T05:13:09Z")
Test certificates do not gave a valid CA hence the message. Untick test, and you get a valid one. ---
**Author:** ![blue](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/3bc359/32.png) [@blue](https://clarionhub.com/u/blue)\ **Post date:** [September 8, 2025, 1:03pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/9 "2025-09-08T13:03:08Z")
I can confirm that there are no problems with certificate. As Bruce wrote, just do not use test. Also, open all ports during process. ---
**Author:** ![Bruce](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/ccd318/32.png) [@Bruce](https://clarionhub.com/u/Bruce)\ **Post date:** [September 8, 2025, 6:24pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/10 "2025-09-08T18:24:12Z")
Only port 80 has to be open (as an incoming port). It can even be handled by a different server (it doesnt have to be serviced by the NetTalk server.) The secure port (which doesnt _have_ to be 443) doesnt need to be active to get the certificate. If Port 80 is not possible, then one can switch from HTTP challenge to DNS challenge. Its a bit more work to setup, but allows for certificates on Networks that block port 80. ---
**Author:** ![blue](https://clarionhub.com/letter_avatar_proxy/v4/letter/b/3bc359/32.png) [@blue](https://clarionhub.com/u/blue)\ **Post date:** [September 10, 2025, 8:00am UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/11 "2025-09-10T08:00:27Z")
With AWS does not work only with port 80. I have to allow all traffic in ACL. At least that was my solution. So when it is time for new certificate, I allow all traffic temporarily and then block when it is finished. That lasts about 30 seconds. I do not know if this is necessary for other cloud providers, and does certification works with only port 80 when server is in local network. I did not had an opportunity to test it. ---
**Author:** ![Rick\_UpperPark](https://clarionhub.com/user_avatar/clarionhub.com/rick_upperpark/32/346_2.png) [@Rick\_UpperPark](https://clarionhub.com/u/Rick_UpperPark)\ **Post date:** [September 10, 2025, 3:15pm UTC](https://clarionhub.com/t/nettalk-and-ssl/7297/12 "2025-09-10T15:15:39Z")
You should recheck your AWS instance security group settings. You do not need to open all ports to get a Let’s Encrypt certificate. I have several setup, both using NetTalk and WinAcme to acquire certificates from LE. The only ports I have open are 80 and 443 to any IP address and the RDP port open to a specific list of IPs for remote access. That’s it. Just 3 ports.