Is curl the good tool

Wed Apr 26 21:13:13 UTC 2023

Thanks for your answer, and your help.

I'm confused, really.

I use certificates since many years,  All my problems are due to terrible error.

In my Debian 11 server with Apache, I'v set CA certificates and server certificates. All have been created this week for new tests.

On the Windows client, I've set certicates (CA and users) ... created 4 years ago...

I use the same scripts, so files have the same names...

So, on Windows, all results were illogical ("weird", sorry).

I've seen my mistake this afternoon. After having set good certificates on Windows client, all is working fine.

I'm very sorry. I apologize.

My question was about curl. It seems to be usefull, but I'm not sure it's the right tool to test the Debian Server and Apache (I use curl on the same server that hosts the web site).

I've used curl successfully (each time, all messages seems to be good, and at end the HTML code of the web page appears - see below):

If Apache don't ask for user authentication:
curl -iv --tlsv1.1 --tls-max 1.1 https://www.my_site.fr

If Apache asks for user authentication:
curl -iv --tlsv1.1 --tls-max 1.1 --cert /etc/ssl/certs/Alex.crt --key /etc/ssl/private/Alex.pem https://www.my_site.fr

For "openssl s_client", as you wrote, on Windows 10, I don't find how to use it successfully. It is kind of a shame. This would probably be useful for testing on Windows without using an Internet browser. Don't bother, I'll figure out how to use, no problems.

I'm sorry.

Thanks for all.

-----------------------------------------------------
A successful example of curl use:

# curl -iv --tlsv1.1 --tls-max 1.1 --cert /etc/ssl/certs/Alex.crt --key /etc/ssl/private/Alex.pem https://www.my_site.fr
*   Trying 192.168.0.100:443...
* Connected to www.my_site.fr (192.168.0.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* 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.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, CERT verify (15):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=FR; ST=France; L=Paris; O=Entreprise; OU=Factory; CN=www.my_site.fr; emailAddress=mail at my_site.fr
*  start date: Jun 12 08:09:15 2018 GMT
*  expire date: Jun  9 08:09:15 2028 GMT
*  common name: www.my_site.fr (matched)
*  issuer: C=FR; ST=France; L=Paris; O=Entreprise; OU=Factory; CN=CA my_site; emailAddress=admin_ca at my_site.fr
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: www.my_site.fr
> User-Agent: curl/7.74.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Wed, 26 Apr 2023 07:29:17 GMT
Date: Wed, 26 Apr 2023 07:29:17 GMT
< Server: Apache/2.4.56 (Debian)
Server: Apache/2.4.56 (Debian)
< Last-Modified: Tue, 25 Apr 2023 12:14:52 GMT
Last-Modified: Tue, 25 Apr 2023 12:14:52 GMT
< ETag: "bc-5fa281219dadd"
ETag: "bc-5fa281219dadd"
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Length: 188
Content-Length: 188
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html
Content-Type: text/html

<
<html>
<head></head>
<body>
You are on a secure site.
</body>
</html>

* Connection #0 to host www.my_site.fr left intact

-----------------------------------------------------

________________________________
De : openssl-users <openssl-users-bounces at openssl.org> de la part de Michael Wojcik via openssl-users <openssl-users at openssl.org>
Envoyé : mercredi 26 avril 2023 20:03
À : openssl-users at openssl.org <openssl-users at openssl.org>
Objet : RE: Is curl the good tool

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
> Viktor Dukhovni
> Sent: Wednesday, 26 April, 2023 13:51
>
> On Wed, Apr 26, 2023 at 07:34:10PM +0000, Michael Wojcik via openssl-
> users wrote:
>
> > > My question: if curl is working fine, can'I conclude my Apache
> configuration and my certificates are fine ?
> >
> > If you didn't build curl yourself, there's no easy way to know what
> > options were used when compiling it; but I believe by default it does
> > not attempt to validate the peer's certificate chain. You have to use
> > options such as --cacert or --capath to do basic validation, --crlfile
> > to check against a CRL, --cert-status to check OCSP stapling if the
> > peer provides it, and so on.
>
> This is not accurate.  Curl will do WebPKI certificate verification by default, and
> fail hard when the certificate does not match.  To get unvalidated "https"
> connections, the "-k" option is required to opt out of validation.

Sorry, my mistake. I see now from the curl documentation that it has a collection of trust anchors it ships with.

Since the OP is either using a private CA or self-signed entity certificates (it's not clear from the original message), curl's stock set of trust anchors obviously shouldn't work for verifying their server. But the OP didn't provide a curl command line so it's not clear what tests were performed.

--
Michael Wojcik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230426/b01291bc/attachment-0001.htm>