Hi, I'm new to stunnel. And I'm trying to configure a server that accepts TCP sockets connections only from clients that have a pre-shared certificate. Looking at the online documentation I found the verifyPeer option, but it is described to be used on client side. Trying to use it on server side I achieved my goal but only if the client has the whole certificate (private + public). My question is: Can I obtain in some way the same result sharing only the public part of the certificate?
Currently I'm using a configuration like this one (skipping the accept and connect options):
[Server] cert=wholeCert.pem verifyPeer=yes
[Client] cert=wholeCert.pem verifyPeer=yes CAFile=wholeCert.pem
and I'm looking for something like:
[Server] cert=wholeCert.pem verifyPeer=yes
[Client] verifyPeer=yes CAFile=publicCert.pem
If I try this second option the server refuses the connection in handshake phase saying that the client didn't provide any certificate. Is there a way to achieve this?
Thank you.
Hello,
Have you tried using only the public part of the CA chain in the “cert=” parameter, client-side ?
Your second option would look like this:
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
verifyPeer=yes
cert=publicCert.pem
CAFile=publicCert.pem
Additionally, if you use the whole chain (Root + Intermediate + … + Leaf certs), you can specifiy a CAFile parameter server-side, and enable the verifyChain parameter on both sides.
Best regards,
Florian Stosse
Information security engineer
Safran Electronics & Defense | Safran Data Systems | Space & Communication
Phone: +33 1 69 82 79 43 • Mobile : +33 6 48 11 16 12
Safran Data Systems
5, avenue des Andes - CS 90101
91978 Courtaboeuf Cedex, France
www.safran-electronics-defense.com
De : Giulio Regazzo [mailto:[email protected]] Envoyé : lundi 16 novembre 2020 09:29 À : [email protected] Objet : [stunnel-users] PSK Configuration
Hi, I'm new to stunnel. And I'm trying to configure a server that accepts TCP sockets connections only from clients that have a pre-shared certificate.
Looking at the online documentation I found the verifyPeer option, but it is described to be used on client side. Trying to use it on server side I achieved my goal but only if the client has the whole certificate (private + public).
My question is: Can I obtain in some way the same result sharing only the public part of the certificate?
Currently I'm using a configuration like this one (skipping the accept and connect options):
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
cert=wholeCert.pem
verifyPeer=yes
CAFile=wholeCert.pem
and I'm looking for something like:
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
verifyPeer=yes
CAFile=publicCert.pem
If I try this second option the server refuses the connection in handshake phase saying that the client didn't provide any certificate.
Is there a way to achieve this?
Thank you.
# " Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés." ****** " This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #
Hi,
using only the public part as cert option in client side results in a load error. Seems that, loading the configuration, stunnel checks the presence of both certificate parts and also that public and private parts are compatible.
The other option you are suggesting is something like the following?
[Server]
cert=wholeCert.pem
verifyChain=yes
CAFile=publicCert.pem
[Client]
verifyChain=yes
CAFile=publicCert.pem
Il giorno lun 16 nov 2020 alle ore 09:49 STOSSE Florian (SAFRAN ELECTRONICS & DEFENSE) [email protected] ha scritto:
Hello,
Have you tried using only the public part of the CA chain in the “cert=” parameter, client-side ?
Your second option would look like this:
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
verifyPeer=yes
cert=publicCert.pem
CAFile=publicCert.pem
Additionally, if you use the whole chain (Root + Intermediate + … + Leaf certs), you can specifiy a CAFile parameter server-side, and enable the verifyChain parameter on both sides.
Best regards,
Florian Stosse
Information security engineer
Safran Electronics & Defense | Safran Data Systems | Space & Communication
Phone: +33 1 69 82 79 43 • Mobile : +33 6 48 11 16 12
Safran Data Systems
5, avenue des Andes - CS 90101
91978 Courtaboeuf Cedex, France
www.safran-electronics-defense.com
*De :* Giulio Regazzo [mailto:[email protected]] *Envoyé :* lundi 16 novembre 2020 09:29 *À :* [email protected] *Objet :* [stunnel-users] PSK Configuration
Hi, I'm new to stunnel. And I'm trying to configure a server that accepts TCP sockets connections only from clients that have a pre-shared certificate.
Looking at the online documentation I found the verifyPeer option, but it is described to be used on client side. Trying to use it on server side I achieved my goal but only if the client has the whole certificate (private
- public).
My question is: Can I obtain in some way the same result sharing only the public part of the certificate?
Currently I'm using a configuration like this one (skipping the accept and connect options):
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
cert=wholeCert.pem
verifyPeer=yes
CAFile=wholeCert.pem
and I'm looking for something like:
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
verifyPeer=yes
CAFile=publicCert.pem
If I try this second option the server refuses the connection in handshake phase saying that the client didn't provide any certificate.
Is there a way to achieve this?
Thank you. # " Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."
" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #
Indeed, I forgot to mention that if you only use the public part in the cert parameter, you need to use the key parameter to provide the private part of the certificate. Here is a sample of a configuration that I use in production
[Client]
client = yes
accept = …..
connect = …...
CAfile = keys/client/ca-chain-client.cert.pem # --> Contains the server leaf public part, the intermediate CA public part and the root CA public part
cert = keys/client/public.pem # --> public part of the client leaf certificate
key = keys/client/private.key # --> private part of the client leaf certificate
checkHost = xxxx # --> verify the Common Name provided in the server certificate
[Server]
CAfile = keys/server/ca-chain-server.cert.pem # --> Contains the client leaf public part, the intermediate CA public part and the root CA public part
cert = keys/server/public.pem
key = keys/server/private.key
client = no
accept = …..
connect = …..
As stated before, I also use the verifyPeer and verifyChain parameters in the main stunnel.conf file to enable mutual authentication.
Best regards,
Florian Stosse
Information security engineer
Safran Electronics & Defense | Safran Data Systems | Space & Communication
Phone: +33 1 69 82 79 43 • Mobile : +33 6 48 11 16 12
Safran Data Systems
5, avenue des Andes - CS 90101
91978 Courtaboeuf Cedex, France
www.safran-electronics-defense.com
De : Giulio Regazzo [mailto:[email protected]] Envoyé : lundi 16 novembre 2020 10:08 À : STOSSE Florian (SAFRAN ELECTRONICS & DEFENSE) Cc : [email protected] Objet : Re: [stunnel-users] PSK Configuration
Hi,
using only the public part as cert option in client side results in a load error. Seems that, loading the configuration, stunnel checks the presence of both certificate parts and also that public and private parts are compatible.
The other option you are suggesting is something like the following?
[Server]
cert=wholeCert.pem
verifyChain=yes
CAFile=publicCert.pem
[Client]
verifyChain=yes
CAFile=publicCert.pem
Il giorno lun 16 nov 2020 alle ore 09:49 STOSSE Florian (SAFRAN ELECTRONICS & DEFENSE) [email protected] ha scritto:
Hello,
Have you tried using only the public part of the CA chain in the “cert=” parameter, client-side ?
Your second option would look like this:
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
verifyPeer=yes
cert=publicCert.pem
CAFile=publicCert.pem
Additionally, if you use the whole chain (Root + Intermediate + … + Leaf certs), you can specifiy a CAFile parameter server-side, and enable the verifyChain parameter on both sides.
Best regards,
Florian Stosse
Information security engineer
Safran Electronics & Defense | Safran Data Systems | Space & Communication
Phone: +33 1 69 82 79 43 • Mobile : +33 6 48 11 16 12
Safran Data Systems
5, avenue des Andes - CS 90101
91978 Courtaboeuf Cedex, France
www.safran-electronics-defense.com
De : Giulio Regazzo [mailto:[email protected]] Envoyé : lundi 16 novembre 2020 09:29 À : [email protected] Objet : [stunnel-users] PSK Configuration
Hi, I'm new to stunnel. And I'm trying to configure a server that accepts TCP sockets connections only from clients that have a pre-shared certificate.
Looking at the online documentation I found the verifyPeer option, but it is described to be used on client side. Trying to use it on server side I achieved my goal but only if the client has the whole certificate (private + public).
My question is: Can I obtain in some way the same result sharing only the public part of the certificate?
Currently I'm using a configuration like this one (skipping the accept and connect options):
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
cert=wholeCert.pem
verifyPeer=yes
CAFile=wholeCert.pem
and I'm looking for something like:
[Server]
cert=wholeCert.pem
verifyPeer=yes
[Client]
verifyPeer=yes
CAFile=publicCert.pem
If I try this second option the server refuses the connection in handshake phase saying that the client didn't provide any certificate.
Is there a way to achieve this?
Thank you.
# " Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés." ****** " This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #
# " Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés." ****** " This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #
-
Giulio Regazzo -
STOSSE Florian (SAFRAN ELECTRONICS & DEFENSE)