From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FORGED_GMAIL_RCVD,FREEMAIL_FROM,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1936 invoked from network); 13 Sep 2023 18:33:48 -0000 Received: from tb-ob0.topicbox.com (64.147.108.117) by inbox.vuxu.org with ESMTPUTF8; 13 Sep 2023 18:33:48 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 6A94033D6F for ; Wed, 13 Sep 2023 14:33:46 -0400 (EDT) (envelope-from bounce.mM79de2065128a8e168e4eb6ea.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 6703228EE919; Wed, 13 Sep 2023 14:33:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=from:to :message-id:date:mime-version:content-type :content-transfer-encoding:list-help:list-id:list-post :list-subscribe:reply-to:subject:list-unsubscribe; s=dkim-1; t= 1694630026; x=1694716426; bh=n7vNtaGSWOfRN7/p6SE5l8PoWoU3tsEGO5j KTOJPUKo=; b=f4NUdOZksreZeq7HmZgJ+Si9dag3sbhw9uIH5Buw4Z8FwhZkukM MSXMrMCYzouyX6b8B/X8orzYIkBT+uQLvU1zczrs5jaf582gD+mUc1yAqBwt6lOu OiAy5VzdnAYqT0vs/1dFDkjrIWQZFBaSCoxK5IFYX0zpvE+p/AkE86gA= From: "Iban Nieto" To: 9fans <9fans@9fans.net> Message-Id: <16946300170.afaf613.904485@composer.9fans.topicbox.com> Date: Wed, 13 Sep 2023 14:33:37 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=16946300171.0a3F.904485 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 0dd99596-5264-11ee-8ab6-e19d232d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UZTgyZGY5ODQxOWUzODUwNC1NNzlkZTIwNjUxMjhhOGUxNjhlNGVi?= =?UTF-8?B?NmVhPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Subject: [9fans] problem with factotum List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M79de2065128a8e168e4eb6ea:1:0r0Pmfc2zViW1woZfp3A1HJKYNiRWPHXsG9U9dsnQhI --16946300171.0a3F.904485 Date: Wed, 13 Sep 2023 14:33:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello! I'm trying to serve https (443) and gemini (1965) under 9front. I've already a working rc-httpd (80) setup and now I would like to start us= ing letsencrypt certificates. Also rc-gemd (gemini server) needs a certificate in order to work. I manage to get the certificate with acmed using the following procedure: ramfs -p cd /tmp auth/rsagen -t 'service=3Dacme role=3Dsign hash=3Dsha256 acct=3Diban@mydoma= in.com' >iban@mydomain.com.key auth/rsa2jwk iban@mydomain.com.key >/sys/lib/tls/acmed/iban@mydomain.com.pub cat iban@mydomain.com.key >/mnt/factotum/ctl auth/rsagen -t 'service=3Dtls role=3Dclient owner=3D*' >mydomain.com.key chmod 600 iban@mydomain.com.key mydomain.com.key cp iban@mydomain.com.key mydomain.com.key /sys/lib/tls/acmed/ auth/rsa2csr 'CN=3Dmydomain.com' /sys/lib/tls/acmed/mydomain.com.key >/sys/= lib/tls/acmed/mydomain.com.csr webfs auth/acmed -t http -o /sys/www/mydomain.com/.well-known/acme-challenge iban= @mydomain.com /sys/lib/tls/acmed/mydomain.com.csr >/sys/lib/tls/acmed/mydom= ain.com.crt I think acmed do the job because the certificate is generated and stored in= the proper location. DNS is in place and working fine, the dir /sys/www/mydomain.com/.well-known= /acme-challenge is already in place as is served by rc-httpd. This a (trimmed) decode of the certificate: auth/pemdecode 'CERTIFICATE' /sys/lib/tls/acmed/mydomain.com.crt | auth/x50= 92pub key proto=3Drsa size=3D2048 ek=3D10001 n=3D1E71BLABLABLABLABAE0CA13254122D6= 00BLABLABLABD4D89D18EB7D7E0BLABLABLABLAC69 subject=3Dmydomain.com Then I try to serve https with: aux/listen1 tcp!*!443 tlssrv -c /sys/lib/tls/acmed/mydomain.com.crt /rc/bin= /rc-httpd/rc-httpd And rc-gemd with: aux/listen1 tcp!*!1965 tlssrv -c /sys/lib/tls/acmed/mydomain.com.crt /rc/bi= n/rc-gemd/rc-gemd Problem is when I try to connect to https://mydomain.com I got this from th= e server side: tlssrv:=C2=A0 tls reports failed: factotum_rsa_open: no key matches proto= =3Drsa service=3Dtls role=3Dclient The same error occurs when I try to connect to gemini using a client: tlssrv:=C2=A0 tls reports failed: factotum_rsa_open: no key matches proto= =3Drsa service=3Dtls role=3Dclient Trying to add the keys to factotum using this: cat /sys/lib/tls/acmed/iban@mydomain.com.key >/mnt/factotum/ctl cat /sys/lib/tls/acmed/mydomain.com.key >/mnt/factotum/ctl I'm still wondering if factotum is aware of these keys... anyway I checked = if the factotum process is running: cpu% pstree | grep -i factotum 130=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=94=9Cfactotum 408=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=94=82=E2=94=94facto= tum 4986=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=94=9Cfactotum 5119=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=94=82=E2=94=94factotum 11793=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=94=82=E2=94=94grep -i factotum But I still got the same error from factotum when I try to use the certific= ates using tlssrv :-( What I'm missing? How to debug the problem? Any help very appreciated :) Many thanks in advance. Iban. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-M79de2= 065128a8e168e4eb6ea Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --16946300171.0a3F.904485 Date: Wed, 13 Sep 2023 14:33:37 -0400 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

I'= m trying to serve https (443) and gemini (1965) under 9front.

I've already a working rc-httpd (80) setup and now = I would like to start using letsencrypt certificates.
Also = rc-gemd (gemini server) needs a certificate in order to work.

I manage to get the certificate with acmed using the fo= llowing procedure:

ramfs -p
cd /tmp
auth/rsagen -t 'service=3Dacme role=3Dsign ha= sh=3Dsha256 acct=3Diban@mydomain.com' >iban@mydomain.com.key
auth/rsa2jwk iban@mydomain.com.key >/sys/lib/tls/acmed/iban@myd= omain.com.pub
cat iban@mydomain.com.key >/mnt/factotum/c= tl
auth/rsagen -t 'service=3Dtls role=3Dclient owner=3D= *' >mydomain.com.key
chmod 600 iban@mydomain.com.key= mydomain.com.key
cp iban@mydomain.com.key mydomain.com.key= /sys/lib/tls/acmed/
auth/rsa2csr 'CN=3Dmydomain.com= 9; /sys/lib/tls/acmed/mydomain.com.key >/sys/lib/tls/acmed/mydomain.com.= csr

webfs
auth/acmed -t ht= tp -o /sys/www/mydomain.com/.well-known/acme-challenge iban@mydomain.com /s= ys/lib/tls/acmed/mydomain.com.csr >/sys/lib/tls/acmed/mydomain.com.crt

I think acmed do the job because the certif= icate is generated and stored in the proper location.
DNS i= s in place and working fine, the dir /sys/www/mydomain.com/.well-known/acme= -challenge is already in place as is served by rc-httpd.
This a (trimmed) decode of the certificate:
= auth/pemdecode 'CERTIFICATE' /sys/lib/tls/acmed/mydomain.com.crt | = auth/x5092pub
key proto=3Drsa size=3D2048 ek=3D10001 n=3D1E= 71BLABLABLABLABAE0CA13254122D600BLABLABLABD4D89D18EB7D7E0BLABLABLABLAC69 su= bject=3Dmydomain.com

Then I try to serve h= ttps with:
aux/listen1 tcp!*!443 tlssrv -c /sys/lib/tls/acm= ed/mydomain.com.crt /rc/bin/rc-httpd/rc-httpd

<= div>And rc-gemd with:
aux/listen1 tcp!*!1965 tlssrv -c /sys= /lib/tls/acmed/mydomain.com.crt /rc/bin/rc-gemd/rc-gemd
Problem is when I try to connect to https://mydomain.com I go= t this from the server side:
tlssrv:  tls reports fail= ed: factotum_rsa_open: no key matches proto=3Drsa service=3Dtls role=3Dclie= nt

The same error occurs when I try to con= nect to gemini using a client:
tlssrv:  tls reports fa= iled: factotum_rsa_open: no key matches proto=3Drsa service=3Dtls role=3Dcl= ient

Trying to add the keys to factotum us= ing this:
cat /sys/lib/tls/acmed/iban@mydomain.com.key >= /mnt/factotum/ctl
cat /sys/lib/tls/acmed/mydomain.com.key &= gt;/mnt/factotum/ctl

I'm still wonderi= ng if factotum is aware of these keys... anyway I checked if the factotum p= rocess is running:

cpu% pstree | grep -i f= actotum
130        = ├factotum
408      &n= bsp;  │└factotum
4986   &= nbsp;    ├factotum
5119  &n= bsp;     │└factotum
11793=        │└grep -i factotum
=

But I still got the same error from factotum wh= en I try to use the certificates using tlssrv :-(

What I'm missing? How to debug the problem?
Any help very appreciated :)

Many thanks in advance.

Iban.
= = --16946300171.0a3F.904485--