Proper way to "update" an expired CA certificate
and continue to use unexpired certificate/key pairs signed by the expired CA certificate. I did some research and found "openssl x509 -in ca.crt -days 3650 -out new-ca.crt -signkey ca.key" which seems to work but want to make sure there aren't any less-than-obvious issues i missed and that there isn't a better way to address the issue. Thanks for your help.
Re: Forthcoming OpenSSL Bug Fix Release
1.1.1 is not susceptible to the CVE that is being fixed in 3.0: /the forthcoming release of OpenSSL version 1.1.1s that is a *bug fix* release/. (highlight added). Dr Paul Dale On 26/10/22 22:17, Matan Giladi wrote: Does 1.1.1s is going to include any security fix? Can you please confirm that the critical issue found in 3.0.6 version is irrelevant for 1.1.1? -Original Message- From: openssl-announce On Behalf Of Ing. Martin Koci, MBA Sent: Tuesday, October 25, 2022 21:36 To:openssl-annou...@openssl.org;openssl-users@openssl.org;openssl-proj...@openssl.org;oss-secur...@lists.openwall.com Subject: Forthcoming OpenSSL Bug Fix Release Hello, In addition to the already announced 3.0.7 release, the OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1s that is a bug fix release. This bug fix release will be made available on Tuesday 1st November 2022 between 1300-1700 UTC too. Yours The OpenSSL Project Team Email secured by Check Point Report Phishing:https://mta-cnf.iaas.checkpoint.com/mta_feedback?id=b3dc9e6004806fac5adb86a1a47504d00416eb2590b631502621736f0652d7ea=3D4CC6C8CB55;48DE55E160E5;C5CEAA199888;=m Email secured by Check Point
RE: SSL_read empty -> close?
> From: openssl-users On Behalf Of Felipe
> Gasper
> Sent: Wednesday, 26 October, 2022 11:15
>
> I’m seeing that OpenSSL 3, when it reads empty on a socket, sends some
> sort of response, e.g.:
>
> - before read
> [pid 42417] read(7276781]>, "", 5) = 0
> [pid 42417] sendmsg(7276781]>, {msg_name=NULL, msg_namelen=0,
> msg_iov=[{iov_base="\0022", iov_len=2}], msg_iovlen=1,
> msg_control=[{cmsg_len=17, cmsg_level=SOL_TLS, cmsg_type=0x1}],
> msg_controllen=17, msg_flags=0}, 0) = -1 EPIPE (Broken pipe)
> - after read
>
> What is that being sent after the read()? Is there a way to disable
> it?
I'd guess it's a TLS Alert Close_notify.
When read/recv on a TCP stream socket returns 0, it means a TCP FIN has been
received from the peer (or possibly some interfering middleman, such as a
firewall). This indicates the peer will no longer be sending any application
data, only at most ACKs and perhaps a RST if conversation does not go quietly
into that good night. Since TLS requires bidirectional communications, that
means the TLS conversation is effectively open, and the local end needs to be
closed; and TLS requires sending a close_notify so the peer knows the
conversation has not been truncated.
Now, the most common cause of a FIN is the peer calling close(), which means it
can't receive that close_notify. But TCP supports half-close, and the peer
*could have* called shutdown(, SD_SEND), indicating that it was done sending
but still wanted to be able to receive data. So the local side has no way of
knowing, at the point where it gets a 0 from read(), that the peer definitely
can't see the close_notify; and thus it's still obligated by the TLS
specification (I believe) to send it.
At any rate, that's my understanding of the requirement for sending
close_notify - I haven't confirmed that in the RFC - and what I suspect OpenSSL
is doing there. I could well be wrong.
If the peer *has* called close, then EPIPE is what you'd expect. Note that on
UNIXy systems this means you should have set the disposition of SIGPIPE to
SIG_IGN to avoid being signaled, but all well-written UNIX programs should do
that anyway. (SIGPIPE, as Dennis Ritchie noted many years ago, was always
intended as a failsafe for poorly-written programs that fail to check for
errors when writing.)
--
Michael Wojcik
How to handle TLS alerts
Hi, I'm trying to understand how to handle TLS alerts, I have set up a callback with SSL_CTX_set_info_callback(_ctx, ssl_info_callback); And I can see alerts sent by the peer, does the application need to call SSL_shutdown upon receiving a fatal alert, or is this done automatically by the OpenSSL library? With my testing, I see my client gets "read SSL3 alert fatal unknown CA" after the call to SSL_connect finishes without error Cheers, Jose
SSL_read empty -> close?
Hello,
I’m seeing that OpenSSL 3, when it reads empty on a socket, sends some
sort of response, e.g.:
- before read
[pid 42417] read(7276781]>, "", 5) = 0
[pid 42417] sendmsg(7276781]>, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\0022", iov_len=2}], msg_iovlen=1,
msg_control=[{cmsg_len=17, cmsg_level=SOL_TLS, cmsg_type=0x1}],
msg_controllen=17, msg_flags=0}, 0) = -1 EPIPE (Broken pipe)
- after read
What is that being sent after the read()? Is there a way to disable it?
Thank you!
cheers,
-Felipe Gasper
自动回复: Re: OpenSSL 1.1.1 Windows dependencies
这是一封自动回复邮件。已经收到您的来信，我会尽快回复。
Re: OpenSSL 1.1.1 Windows dependencies
On Wed, Oct 26, 2022 at 11:50:16AM -0400, Viktor Dukhovni wrote: > On Wed, Oct 26, 2022 at 11:15:25AM +0100, Matt Caswell wrote: > > > > I'm not promising anything. But if you send me the captures I can take a > > > look at them. > > > > I've taken a look at the captures for the working and non-working scenarios. > > > > Do I understand correctly that your application is acting as the server > > in this setup? > > > > I have compared the working and non-working captures. In both cases the > > ClientHello is successfully received, and the server responds with a > > ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. > > Aside from normal variations between one session and another, AFAICT, > > the ClientHello and the server's response messages all look identical > > other than the server obviously has a different Certificate. The > > Certificates themselves also look identical to each other other than the > > subject/subjectaltname being for a different server. The intermediate > > certs are the same in both cases. > > > > Following the server's ServerHelloDone the client continues with a > > ClientKeyExchange message in the working case. In the non-working case > > the the client immediately closes the TCP connection without sending any > > kind of alert. > > See longish thread at: > > https://marc.info/?l=postfix-users=166584042429636=2 > > which describes a remarkably similar set of symptoms observed after a > Microsoft patch update. Today the OP posted that a more follow-on patch > appears to have resolved the problem. TL;DR: progress on identifying the issue begins with: https://marc.info/?l=postfix-users=166585652703462=2 -- Viktor.
自动回复: Re: OpenSSL 1.1.1 Windows dependencies
这是一封自动回复邮件。已经收到您的来信，我会尽快回复。
Re: OpenSSL 1.1.1 Windows dependencies
On Wed, Oct 26, 2022 at 11:15:25AM +0100, Matt Caswell wrote: > > I'm not promising anything. But if you send me the captures I can take a > > look at them. > > I've taken a look at the captures for the working and non-working scenarios. > > Do I understand correctly that your application is acting as the server > in this setup? > > I have compared the working and non-working captures. In both cases the > ClientHello is successfully received, and the server responds with a > ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. > Aside from normal variations between one session and another, AFAICT, > the ClientHello and the server's response messages all look identical > other than the server obviously has a different Certificate. The > Certificates themselves also look identical to each other other than the > subject/subjectaltname being for a different server. The intermediate > certs are the same in both cases. > > Following the server's ServerHelloDone the client continues with a > ClientKeyExchange message in the working case. In the non-working case > the the client immediately closes the TCP connection without sending any > kind of alert. See longish thread at: https://marc.info/?l=postfix-users=166584042429636=2 which describes a remarkably similar set of symptoms observed after a Microsoft patch update. Today the OP posted that a more follow-on patch appears to have resolved the problem. > This really looks like a problem on the client side to me. Yes, the client just hangs up. A known. Disabling session tickets on server appears to help in some cases (for no obvious reason). Applying the follow-on update is a better solution if applicable. -- Viktor.
I have finally figured out how to export Private Key from Fortigate firewall and successfully install Godaddy Wildcard SSL certificate in UniFi Cloud Key Gen 2 Plus Network Controller
Subject: I have finally figured out how to export Private Key from Fortigate firewall and successfully install Godaddy Wildcard SSL certificate in UniFi Cloud Key Gen 2 Plus Network Controller Good day from Singapore, Author: Mr. Turritopsis Dohrnii Teo En Ming Country: Singapore Date: 26 Oct 2022 Wednesday I have finally figured out how to export Private Key from Fortigate firewall and successfully install Godaddy Wildcard SSL certificate in UniFi Cloud Key Gen 2 Plus Network Controller because I have finally found the correct reference guides! Please refer to the following list. Reference Guides = Youtube video: Ubiquiti Networks UniFi OS SSL Certificate Installation Link: https://www.youtube.com/watch?v=WxhY71ebc9o Guide: Extracting Private Key from FortiGate Firewall Link: https://infosecmonkey.com/extracting-private-key-from-fortigate-firewall/ Guide: Extracting private key from FortiGate SSL Certificates Link: https://www.linkedin.com/pulse/extracting-private-key-from-fortigate-ssl-kuganesan-srijeyanthan Guide: How to decrypt an RSA private key and then use it in kyrtool to merge the SSL certificates. Link: https://support.hcltechsw.com/csm?id=kb_article_article=KB0098900 Guide: How to Fix an Encrypted SSL Private Key Link: https://serverpilot.io/docs/how-to-fix-an-encrypted-ssl-private-key/ DETAILED INSTRUCTIONS FROM TEO EN MING === Login to the Fortigate 201F firewall and run the following commands using CLI. config vpn certificate local edit show full You will see something like: -BEGIN ENCRYPTED PRIVATE KEY- <---snipped---> -END ENCRYPTED PRIVATE KEY- Save the above encrypted private key as encrypted.txt in notepad or notepad++ in Windows Server. Then decrypt the encrypted private key using the openssl linux command. openssl rsa -in encrypted.txt -out plain.txt Download and install Keystore Explorer in Windows Server. Launch KeyStore Explorer 5.5.1. Click Create a new KeyStore. Click JKS. Click OK. Click Import Key Pair. Click OpenSSL. Click OK. Uncheck Encrypted Private Key. Browse OpenSSL Private Key File. (plain.txt) Browse Certificate(s) File. (chain.crt generated from Godaddy Wildcard SSL certificate) Click Import. Enter Alias: unifi Click OK. Enter New Password: aircontrolenterprise Confirm New Password: aircontrolenterprise Click OK. Click OK. Click Save. Enter New Password: aircontrolenterprise Confirm New Password: aircontrolenterprise Save KeyStore As: keystore (filename without extension) Click Save. Launch WinSCP in Windows Server. Transfer keystore file to /srv/unifi/data. Browse to /data/unifi-core/config. Create backup folder. Move default/original unifi-core.crt and unifi-core.key to above backup folder. Upload plain.txt to /data/unifi-core/config as unifi-core.key. Upload chain.crt (generated from Godaddy Wildcard SSL certificate) to /data/unifi-core/config as unifi-core.crt Reboot UniFi Cloud Key Gen 2 Plus network controller. You MUST reboot for it to take effect! SUCCESS! Browse to https://cloudkey.teo-en-ming-corp.com on your favorite web browser. You should see a padlock icon on the browser address bar. This means that the Wildcard SSL certificate was installed correctly. I started doing it at 5.00 PM and completed doing it at 6.00 PM Singapore time on 26 Oct 2022 Wednesday. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com
Re: Forthcoming OpenSSL Bug Fix Release
On 26/10/2022 12:17, Matan Giladi wrote: Does 1.1.1s is going to include any security fix? 1.1.1s is a bug fix release only. There are no security fixes. Can you please confirm that the critical issue found in 3.0.6 version is irrelevant for 1.1.1? The critical issue applies to 3.0.0 - 3.0.6 only. It does not apply to any 1.1.1 release. Matt -Original Message- From: openssl-announce On Behalf Of Ing. Martin Koci, MBA Sent: Tuesday, October 25, 2022 21:36 To: openssl-annou...@openssl.org; openssl-users@openssl.org; openssl-proj...@openssl.org; oss-secur...@lists.openwall.com Subject: Forthcoming OpenSSL Bug Fix Release Hello, In addition to the already announced 3.0.7 release, the OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1s that is a bug fix release. This bug fix release will be made available on Tuesday 1st November 2022 between 1300-1700 UTC too. Yours The OpenSSL Project Team Email secured by Check Point Report Phishing: https://mta-cnf.iaas.checkpoint.com/mta_feedback?id=b3dc9e6004806fac5adb86a1a47504d00416eb2590b631502621736f0652d7ea=3D4CC6C8CB55;48DE55E160E5;C5CEAA199888;=m Email secured by Check Point
Re: OpenSSL 1.1.1 Windows dependencies
On 24/10/2022 10:17, Matt Caswell wrote: On 22/10/2022 16:02, David Harris wrote: On 21 Oct 2022 at 13:50, Michael Wojcik via openssl-users wrote: That was my initial thought too, except that if it were firewall-related, the initial port 587 connection would be blocked, and it isn't - the failure doesn't happen until after STARTTLS has been issued. Not necessarily. That's true for a first-generation port-blocking firewall, but not for a packet-inspecting one. There are organizations which use packet-inspecting firewalls to block STARTTLS because they enforce their own TLS termination, in order to inspect all incoming traffic for malicious content and outgoing traffic for exfiltration. I now have wireshark captures showing the exchanges between the working instance and the non-working instance respectively; the problem is definitely happening after STARTTLS has been issued and during the TLS handshake. I'm not high-level enough to be able to make any sense of the negotiation data though. The wireshark capture is quite short (22 items in the list) and I don't mind making it available if it would be useful to anyone. I'm not promising anything. But if you send me the captures I can take a look at them. I've taken a look at the captures for the working and non-working scenarios. Do I understand correctly that your application is acting as the server in this setup? I have compared the working and non-working captures. In both cases the ClientHello is successfully received, and the server responds with a ServerHello, Certificate, ServerKeyExchange and ServerHelloDone message. Aside from normal variations between one session and another, AFAICT, the ClientHello and the server's response messages all look identical other than the server obviously has a different Certificate. The Certificates themselves also look identical to each other other than the subject/subjectaltname being for a different server. The intermediate certs are the same in both cases. Following the server's ServerHelloDone the client continues with a ClientKeyExchange message in the working case. In the non-working case the the client immediately closes the TCP connection without sending any kind of alert. This really looks like a problem on the client side to me. Or at least that's where attention will have to be focused for now to figure out what went wrong. The client side has made the decision to close the connection (or plausibly some middlebox has, but this seems unlikely given that the handshakes up until that point look virtually identical). Is there any possibility of getting any logs from the client side to see why it has decided to abort the connection? Matt
