Re: SIGINT vs. SIGTERM?

2024-08-25 Thread Jeffrey Walton via curl-users
On Sun, Aug 25, 2024 at 7:21 PM Paul Gilmartin via curl-users
 wrote:
>
> Don't consider this a problem report; I've worked around it.
>
> On 8/25/24 15:20, Daniel Stenberg wrote:
>
> > On Sun, 25 Aug 2024, Paul Gilmartin via curl-users wrote:
> >
> >> Running curl from a script I attempt to terminate a long download.
> >>kill -INT  curl has no effect
> >>kill -TERM curl terminates curl.
> >>
> >> Does curl trap SIGINT for some special behavior, leaving the default 
> >> SIGTERM?
> >
> > SIGINT is the signal that hitting ctrl-c in a terminal sends to the 
> > application like when aborting a slow transfer. I use that frequently with 
> > curl and I have never seen or experienced a problem with that. So no, curl 
> > does not ignore SIGINT.
> >  .
> 800 $ uname -msv
> Darwin Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:00 PDT 2024; 
> root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64
> 801 $ curl --version
> curl 8.9.1 (x86_64-apple-darwin23.4.0) libcurl/8.9.1 OpenSSL/3.3.1 
> (SecureTransport) zlib/1.2.12 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 
> libssh2/1.11.0 nghttp2/1.61.0 librtmp/2.3
> Release-Date: 2024-07-31
>
> curl from the command line works as you describe.
> I have curl buried in scripts with complicated options.
> In my top script trapped a signal and killed the curl
> process.  SIGTERM worked; SIGINT didn't.
>
> Hard to reproduce.

Look at your signal handlers. They are _not_ MT-safe. If you try to do
some things in them -- like log a printf("signal received: %d", sig);
-- then you are in undefined behavior territory. I've seen signal
handlers hang because of things like logging using printf. If you want
to log in your signal handler, then call write(2) directly.

Jeff
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html


Re: Cert auth issue where Server CN appears to match Hostname

2024-10-03 Thread Jeffrey Walton via curl-users
On Thu, Oct 3, 2024 at 2:26 PM Adam Retter via curl-users
 wrote:
>
> I have a Web Server that requires certificate authentication, and I am
> trying to connect to it using curl (version 7.81.0-1ubuntu1.18) and a
> client certificate.
> Unfortunately I am getting the following error from curl:
>
> curl: (60) SSL: no alternative certificate subject name matches target
> host name 'tekrar.lacuna.evolvedbinary.com'.
>
> The full curl command I am running is:
>
> curl -vv --cacert /etc/puppetlabs/puppetserver/ca/ca_crt.pem --cert
> /etc/puppetlabs/puppet/ssl/certs/tekrar.lacuna.evolvedbinary.com.pem
> --key 
> /etc/puppetlabs/puppet/ssl/private_keys/tekrar.lacuna.evolvedbinary.com.pem
> https://tekrar.lacuna.evolvedbinary.com:8081
>
> The full output from curl looks like:
>
> *   Trying 172.30.1.254:8081...
> * Connected to tekrar.lacuna.evolvedbinary.com (172.30.1.254) port 8081 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> *  CAfile: /etc/puppetlabs/puppetserver/ca/ca_crt.pem
> *  CApath: /etc/ssl/certs
> * TLSv1.0 (OUT), TLS header, Certificate Status (22):
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> * TLSv1.2 (IN), TLS header, Certificate Status (22):
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> * TLSv1.2 (IN), TLS header, Finished (20):
> * TLSv1.2 (IN), TLS header, Supplemental data (23):
> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
> * TLSv1.3 (IN), TLS handshake, Request CERT (13):
> * TLSv1.3 (IN), TLS handshake, Certificate (11):
> * TLSv1.3 (IN), TLS handshake, CERT verify (15):
> * TLSv1.3 (IN), TLS handshake, Finished (20):
> * TLSv1.2 (OUT), TLS header, Finished (20):
> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.3 (OUT), TLS handshake, Certificate (11):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.3 (OUT), TLS handshake, CERT verify (15):
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.3 (OUT), TLS handshake, Finished (20):
> * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
> * ALPN, server did not agree to a protocol
> * Server certificate:
> *  subject: C=GB; ST=Devon; L=Sampford Peverell; O=Evolved Binary;
> OU=SysOps; CN=tekrar.lacuna.evolvedbinary.com;
> emailAddress=sys...@evolvedbinary.com
> *  start date: Jan 24 16:54:18 2024 GMT
> *  expire date: Jan 23 16:54:18 2027 GMT
> *  subjectAltName does not match tekrar.lacuna.evolvedbinary.com
> * SSL: no alternative certificate subject name matches target host
> name 'tekrar.lacuna.evolvedbinary.com'
> * Closing connection 0
> * TLSv1.2 (OUT), TLS header, Supplemental data (23):
> * TLSv1.3 (OUT), TLS alert, close notify (256):
> curl: (60) SSL: no alternative certificate subject name matches target
> host name 'tekrar.lacuna.evolvedbinary.com'
> More details here: https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
>
> As far as I can see hostname matches the CN in the server certificate.
> So I am not sure why it is complaining about ALT names. Any ideas?
>
> I have access to the client, server, and cert files if you would like
> me to check anything?

Hostnames always go in the Subject Alt Name (SAN). The hostname in the
CN must also be present in the SAN. The hostname has to be listed
twice in this case. So get a new certificate issued for the host, and
ensure tekrar.lacuna.evolvedbinary.com is present in the SAN.

Public CA's used to issue a certificate with the domain name in the
CN, and the hostnames in the SAN. Nowadays the CN is NOT RECOMMENDED.
The rules for Public CA's can be found in the CA/Browser Forum
Baseline Requirements (BR),
.
The section of interest is 7.1.4.3, Subscriber Certificate Common Name
Attribute (p. 108).

My rule of thumb is, all hostnames go in the SAN. CN is displayed to
the user, so make it a friendly name, like "Evolved Binary Website" or
similar. I do not follow the CA/B BR NOT RECOMMENDED -- I still issue
with the CN on my networks.

Jeff
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html


Re: Strange behavior processing SSL certs between a Windows 11 system running Python 3.13.1 and a Windows 10 system running Python 3.8.5

2024-12-28 Thread Jeffrey Walton via curl-users
On Sat, Dec 28, 2024 at 8:34 AM Dick Brooks via curl-users <
curl-users@lists.haxx.se> wrote:

> *[...]*
>
> I’ve encountered some unexpected behavior between two systems using the
> exact same piece of code – any ideas why this might be happening:
>
>
>
> FROM ROADWARRIOR (Win 11) (shows the signing certificate info)
>
>
>
> > ServerURL :  https://pypi.org/project/sag-reader/1.0.4/#files
>
> > Subject :  CN=GlobalSign Atlas R3 DV TLS CA 2024 Q2
>
> > Issuer :  CN=GlobalSign
>
> > SourceCertificateComplete :  [(('Subject', 'C=BE, O=GlobalSign
> nv-sa, CN=GlobalSign Atlas R3 DV TLS CA 2024 Q2'), ('Issuer',
> 'OU=GlobalSign Root CA - R3, O=GlobalSign, CN=GlobalSign'), ('Version',
> '2'), ('Serial Number',
> '00:80:4e:00:3a:27:2b:c5:18:e3:4d:a4:b1:fc:9b:78:33:'), ('Signature
> Algorithm', 'sha256WithRSAEncryption'), ('Start Date', '2024-01-17 03:24:32
> GMT'), ('Expire Date', '2026-01-17 00:00:00 GMT')
>
>
>
>
>
> FROM WARP9 (Win 10) (shows the issued SSL Certificate subject info – the
> leaf node)
>
>
>
> > ServerURL :  https://pypi.org/project/sag-reader/1.0.4/#files
>
> > Subject :  CN=pypi.org
>
> > Issuer :  CN=GlobalSign Atlas R3 DV TLS CA 2024 Q2
>
> > SourceCertificateComplete :  [(('Subject', 'CN=pypi.org'),
> ('Issuer', 'C=BE, O=GlobalSign nv-sa, CN=GlobalSign Atlas R3 DV TLS CA 2024
> Q2'), ('Version', '2'), ('Serial Number',
> '01:06:a3:43:b1:24:03:82:30:1a:c9:27:d9:3f:23:4b:'), ('Signature
> Algorithm', 'sha256WithRSAEncryption'), ('Start Date', '2024-04-23 04:22:05
> GMT'), ('Expire Date', '2025-05-25 04:22:04 GMT')
>
>
>
> NOTE: I receive the same results on both machines when I run the code
> interactively (the win 10 results):
>
>
>
> import pycurl, certifi
>
> curl = pycurl.Curl()
>
> curl.setopt(pycurl.CAINFO, certifi.where())
>
> curl.setopt(pycurl.SSL_VERIFYPEER, 1)
>
> curl.setopt(pycurl.SSL_VERIFYHOST, 2)
>
> curl.setopt(pycurl.OPT_CERTINFO, 1)
>
> curl.setopt(pycurl.NOBODY, 1)
>
> #ServerURL="https://pypi.org/project/sag-reader/";
>
> ServerURL="https://softwareassuranceguardian.com/SAG_CTR";
>
> curl.setopt(pycurl.URL, ServerURL) # https://pypi.org/project/sag-reader/
>
> buffer = curl.perform_rb()
>
> ServerCert = curl.getinfo(pycurl.INFO_CERTINFO)
>
> certinfo = ServerCert[0]
>
> print(certinfo)
>
> certinfo_dict = dict()
>
> for entry in certinfo:
>
>
>
>certinfo_dict[entry[0]] = entry[1]
>
>print(certinfo_dict[entry[0]])
>
>for item in certinfo_dict['Subject'].split(", "):
>
>   Cert_Subject = item
>
>   print("ITEM: ", item)
>
>   if item.find("=") != -1 :
>
> fieldname =
> item.split("=")[0].strip()
>
> fieldvalue = item.split("=")[1]
>
> if fieldname == "CN" :
>
>CN_Name =
> fieldvalue
>
>print("CN= ",
> CN_Name)
>

It is not clear (to me) what your complaint is. You did not state it other
than to say you experienced unexpected behavior.

To state the obvious: the dumps you are showing are for the host at pypi.org.
The code you are showing is hardcoded for the host
softwareassuranceguardian.com.

You can use OpenSSL to dump the web server's certificate. Maybe that will
give you a good baseline.

$ openssl s_client -connect softwareassuranceguardian.com:443 -servername
softwareassuranceguardian.com | openssl x509 -text -noout
Connecting to 18.220.83.76
depth=0 CN=softwareassuranceguardian.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN=softwareassuranceguardian.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN=softwareassuranceguardian.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4721225938421497953 (0x418529fa13f94061)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=
http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate
Authority - G2
Validity
Not Before: Apr 25 07:09:28 2024 GMT
Not After : Apr 23 11:58:54 2025 GMT
Subject: CN=softwareassuranceguardian.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b8:f8:06:85:57:b7:a6:50:22:5e:90:a2:d5:23:
f9:6e:c0:aa:e4:da:ba:66:9e:1d:38:fc:e4:98:ab:
93:59:33:1e:93:5e:c5:e5:c7:e4:c4:91:71:ce:4b:
40:44:65:36:0b:0e:32:ac:b8:c5:68:e5:db:ce:ce:
33:02:3c:32:ce:06:27:1c:f0:79:0e:a7:41:de:7b:
c9:d6:be:0d:ed:6a:37:61:7c:8b:a2:b2:8f:6b:da:
66:70:3

Re: Strange behavior processing SSL certs between a Windows 11 system running Python 3.13.1 and a Windows 10 system running Python 3.8.5

2024-12-28 Thread Jeffrey Walton via curl-users
 On Sat, Dec 28, 2024 at 4:50 PM Dick Brooks via curl-users
 wrote:
>
> That certainly fits with  the scenario I’m seeing between Win 11 and Win 10 
> installations.
>
>
>
> Looks like a libcurl update is in order for my software deployment.
>
>
>
> Thank you very much for helping to resolve this.
>
>
>
> Well done, Sir.

For completeness, the RFC's state the web server's certificate comes
first in the order, followed by CA certificates needed to validate the
preceding certificate. If WIndows is not presenting that way, then it
is a WIndows bug.

From RFC 5246, TLS 1.2, Section 7.4.2. Server Certificate:

  When this message will be sent:

 The server MUST send a Certificate message whenever the agreed-
 upon key exchange method uses certificates for authentication
 (this includes all key exchange methods defined in this document
 except DH_anon).  This message will always immediately follow the
 ServerHello message.
 ...

  certificate_list
 This is a sequence (chain) of certificates.  The sender's
 certificate MUST come first in the list.  Each following
 certificate MUST directly certify the one preceding it.  Because
 certificate validation requires that root keys be distributed
 independently, the self-signed certificate that specifies the root
 certificate authority MAY be omitted from the chain, under the
 assumption that the remote end must already possess it in order to
 validate it in any case.

RFC 8446, TLS 1.3, has similar language. But in Section 4.4.2.
Certificate, the RFC says this:

  Note: Prior to TLS 1.3, "certificate_list" ordering required each
  certificate to certify the one immediately preceding it; however,
  some implementations allowed some flexibility.  Servers sometimes
  send both a current and deprecated intermediate for transitional
  purposes, and others are simply configured incorrectly, but these
  cases can nonetheless be validated properly.  For maximum
  compatibility, all implementations SHOULD be prepared to handle
  potentially extraneous certificates and arbitrary orderings from any
  TLS version, with the exception of the end-entity certificate which
  MUST be first.

Jeff
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
Etiquette:   https://curl.se/mail/etiquette.html