* [9fans] problem with factotum
@ 2023-09-13 18:33 Iban Nieto
2023-09-13 19:17 ` igor
2023-09-13 21:54 ` Skip Tavakkolian
0 siblings, 2 replies; 6+ messages in thread
From: Iban Nieto @ 2023-09-13 18:33 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
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 following procedure:
ramfs -p
cd /tmp
auth/rsagen -t 'service=acme role=sign hash=sha256 acct=iban@mydomain.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=tls role=client owner=*' >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=mydomain.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/mydomain.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/x5092pub
key proto=rsa size=2048 ek=10001 n=1E71BLABLABLABLABAE0CA13254122D600BLABLABLABD4D89D18EB7D7E0BLABLABLABLAC69 subject=mydomain.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/bin/rc-gemd/rc-gemd
Problem is when I try to connect to https://mydomain.com I got this from the server side:
tlssrv: tls reports failed: factotum_rsa_open: no key matches proto=rsa service=tls role=client
The same error occurs when I try to connect to gemini using a client:
tlssrv: tls reports failed: factotum_rsa_open: no key matches proto=rsa service=tls role=client
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 ├factotum
408 │└factotum
4986 ├factotum
5119 │└factotum
11793 │└grep -i factotum
But I still got the same error from factotum when 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.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-M79de2065128a8e168e4eb6ea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 4768 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] problem with factotum
2023-09-13 18:33 [9fans] problem with factotum Iban Nieto
@ 2023-09-13 19:17 ` igor
2023-09-13 21:54 ` Skip Tavakkolian
1 sibling, 0 replies; 6+ messages in thread
From: igor @ 2023-09-13 19:17 UTC (permalink / raw)
To: 9fans; +Cc: igor
A working setup with tlssrv(8) and acmed(8) is documented here:
• https://9lab.org/plan9/web-server-with-go-based-static-site-generator-hugo/#https-port-443
A comparison of those steps with your steps below might reveal
the issue.
Quoth Iban Nieto <iban.nieto@gmail.com>:
> 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 following procedure:
>
> ramfs -p
> cd /tmp
> auth/rsagen -t 'service=acme role=sign hash=sha256 acct=iban@mydomain.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=tls role=client owner=*' >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=mydomain.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/mydomain.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/x5092pub
> key proto=rsa size=2048 ek=10001 n=1E71BLABLABLABLABAE0CA13254122D600BLABLABLABD4D89D18EB7D7E0BLABLABLABLAC69 subject=mydomain.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/bin/rc-gemd/rc-gemd
>
> Problem is when I try to connect to https://mydomain.com I got this from the server side:
> tlssrv: tls reports failed: factotum_rsa_open: no key matches proto=rsa service=tls role=client
>
> The same error occurs when I try to connect to gemini using a client:
> tlssrv: tls reports failed: factotum_rsa_open: no key matches proto=rsa service=tls role=client
>
> 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 ├factotum
> 408 │└factotum
> 4986 ├factotum
> 5119 │└factotum
> 11793 │└grep -i factotum
>
> But I still got the same error from factotum when 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.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-M8e647fed602d71bb73a3cfb7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] problem with factotum
2023-09-13 18:33 [9fans] problem with factotum Iban Nieto
2023-09-13 19:17 ` igor
@ 2023-09-13 21:54 ` Skip Tavakkolian
2023-09-14 16:49 ` Iban Nieto
1 sibling, 1 reply; 6+ messages in thread
From: Skip Tavakkolian @ 2023-09-13 21:54 UTC (permalink / raw)
To: 9fans
Do you have the right factotum in the namespace you're working on?
Listing /srv should give a clue.
On Wed, Sep 13, 2023 at 2:03 PM Iban Nieto <iban.nieto@gmail.com> wrote:
>
> 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 following procedure:
>
> ramfs -p
> cd /tmp
> auth/rsagen -t 'service=acme role=sign hash=sha256 acct=iban@mydomain.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=tls role=client owner=*' >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=mydomain.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/mydomain.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/x5092pub
> key proto=rsa size=2048 ek=10001 n=1E71BLABLABLABLABAE0CA13254122D600BLABLABLABD4D89D18EB7D7E0BLABLABLABLAC69 subject=mydomain.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/bin/rc-gemd/rc-gemd
>
> Problem is when I try to connect to https://mydomain.com I got this from the server side:
> tlssrv: tls reports failed: factotum_rsa_open: no key matches proto=rsa service=tls role=client
>
> The same error occurs when I try to connect to gemini using a client:
> tlssrv: tls reports failed: factotum_rsa_open: no key matches proto=rsa service=tls role=client
>
> 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 ├factotum
> 408 │└factotum
> 4986 ├factotum
> 5119 │└factotum
> 11793 │└grep -i factotum
>
> But I still got the same error from factotum when 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.
> 9fans / 9fans / see discussions + participants + delivery options Permalink
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-Mf1c7195bd89fa92ac5074379
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] problem with factotum
2023-09-13 21:54 ` Skip Tavakkolian
@ 2023-09-14 16:49 ` Iban Nieto
2023-09-14 20:51 ` ori
0 siblings, 1 reply; 6+ messages in thread
From: Iban Nieto @ 2023-09-14 16:49 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
Hello!
@igor I've followed some of your instructions (as you can see, the same procedure for acmed), but my setup is a bit different than yours. Could you please tell me what's wrong with my setup? (this is my very first time using tls in 9front).
@skip I've performed the entire procedure in the same namespace and in another ns by using line per line commands in the console and using scripts, all with the same luck. Also /srv/factotum is in place in my namespace as I have auth/factotum in my $home/lib/profile.
I guess that the problem could be factotum or the way the keys are added, but the thing is that I've already working factotum with ssh keys, so I have NO IDEA what's going on this case. Actually, after reading lots of manuals I can't find where is the problem, and with some probability is a silly one.
Thank you again!
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-Mab6b11e0e4952d3ee3bb07eb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 1712 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] problem with factotum
2023-09-14 16:49 ` Iban Nieto
@ 2023-09-14 20:51 ` ori
2023-09-29 8:02 ` Iban Nieto
0 siblings, 1 reply; 6+ messages in thread
From: ori @ 2023-09-14 20:51 UTC (permalink / raw)
To: 9fans
Quoth Iban Nieto <iban.nieto@gmail.com>:
> @skip I've performed the entire procedure in the same namespace and in another ns by using line per line commands in the console and using scripts, all with the same luck. Also /srv/factotum is in place in my namespace as I have auth/factotum in my $home/lib/profile.
is the namespace you're running the web server in using that factotum?
by default, aux/listen runs as none in a new namespace.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-M87ca5928a29a01a7ebda6ac6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] problem with factotum
2023-09-14 20:51 ` ori
@ 2023-09-29 8:02 ` Iban Nieto
0 siblings, 0 replies; 6+ messages in thread
From: Iban Nieto @ 2023-09-29 8:02 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
I've resolved the issue and now I'm able to serve https.
As you already know, the problem is always the same and it's between the chair and the table ;-)
As noted by @ori (thank you), the issue was that I was trying to load the key from my own namespace instead of none. Also I was missing to reboot the server in order to load the key from /cfg/$sysname/cpuserver through factotum.
Thanks again!
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te82df98419e38504-Me28f03ee5bcff421ea52d6bd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 1229 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-09-29 8:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-13 18:33 [9fans] problem with factotum Iban Nieto
2023-09-13 19:17 ` igor
2023-09-13 21:54 ` Skip Tavakkolian
2023-09-14 16:49 ` Iban Nieto
2023-09-14 20:51 ` ori
2023-09-29 8:02 ` Iban Nieto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).