Re: relayd TLS handshake failure
Another update on this issue: httpd is perfectly capable of negotiating a TLS handshake with my keypair. The error only happens in relayd. -- Regards, David E. McMackins II www.mcmackins.org On Thu, 2024-08-22 at 07:20 -0500, David McMackins II wrote: > Thanks for the tips. No mention of ecdsa in my acme-client.conf, and > I've tried both the fullchain and leaf certs to the same effect. > > This morning I also tried a different gemini client just to make sure > it wasn't a lagrange-specific issue, but alas. >
Re: relayd TLS handshake failure
The only difference I notice between our configs is that your
hostname.crt simlink goes to the leaf certificate and not the full
chain. I've tried that as well to the same effect. This is leading me
again to thinking it's to do with sparc64 architecture (or big endian
generally) and not my configs.
--
Regards,
David E. McMackins II
www.mcmackins.org
On Wed, 2024-08-21 at 20:13 +0200, Sven Wolf wrote:
> Hi David,
>
> I run vger 2.0.1 on amd64 as written by solene.
> my relayd.conf looks like yours
>
> cat /etc/relayd.conf
>
>
> log connection
> tcp protocol "gemini" {
> tls keypair
> }
>
> relay "gemini" {
> listen on port 1965 tls
> protocol "gemini"
> forward to 127.0.0.1 port 8965
> }
>
> I also use the acme-client to create/update the cert.
>
> cat /etc/acme-client.conf
> domain {
> alternative names { }
> domain key "/etc/ssl/private/.key"
> domain certificate "/etc/ssl/.pem"
> domain full chain certificate
> "/etc/ssl/.fullchain.pem"
> sign with letsencrypt
> }
>
> And I also created the symlink for the certificate
> /etc/ssl/.crt -> .pem
>
> I don't have any problems with this setup.
>
> Best regards,
> Sven
>
> On 8/21/24 15:25, David McMackins II wrote:
> > Thanks. I should have mentioned I did already try adding the "tls
> > tlsv1" directive in the gemini protocol section and it yielded the
> > same
> > result, so I removed it before opening this thread.
> >
>
>
Re: relayd TLS handshake failure
Thanks for the tips. No mention of ecdsa in my acme-client.conf, and
I've tried both the fullchain and leaf certs to the same effect.
This morning I also tried a different gemini client just to make sure
it wasn't a lagrange-specific issue, but alas.
--
Regards,
David E. McMackins II
www.mcmackins.org
On Wed, 2024-08-21 at 16:42 +, Lucas Gabriel Vuotto wrote:
> On Wed, Aug 21, 2024 at 07:32:34AM GMT, David McMackins II wrote:
> > Hello.
> >
> > I'm trying to set up a gemini server using vger and following the
> > instructions in its git repo: https://tildegit.org/solene/vger
> >
> > However, the TLS handshake with relayd is failing as follows:
> >
> > rsae_send_imsg: privenc poll timeout, keyop #0
> > relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS
> > handshake error: handshake failed: error:1402D438:SSL
> > routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid
> > argument
> > relay_dispatch_ca: privenc result after timeout
> >
> > I reached out to the vger developer first, and there doesn't appear
> > to
> > be anything wrong with my relayd config:
> >
> > log connection
> >
> > tcp protocol "gemini" {
> > tls keypair retro.inetcc.org
> > }
> >
> > relay "gemini" {
> > listen on retro.inetcc.org port 1965 tls
> > protocol "gemini"
> > forward to 127.0.0.1 port 11965
> > }
> >
> >
> > My TLS cert/key were generated using acme-client, and I made a
> > symlink
> > for relayd to find the certificate since the default name from
> > acme-
> > client is not what relayd is expecting.
> >
> > I'm wondering if this is actually a bug specific to sparc64 which
> > I'm
> > running this on.
>
> Wild guesses that usually bite me with relayd:
>
> - if my memory serves me right, relayd only supports RSA keys. If you
> added "ecdsa" to your acme-client.conf, then that's not going to
> fly.
> - double-check that you linked the fullchain, not the only the leaf
> cert.
Re: relayd TLS handshake failure
On 2024/08/21 22:54, Omar Polo wrote: > On 21/08/24 14:49, Kirill A. Korinsky wrote: > > On Wed, 21 Aug 2024 14:32:34 +0200, > > David McMackins II wrote: > >> rsae_send_imsg: privenc poll timeout, keyop #0 > >> relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS > >> handshake error: handshake failed: error:1402D438:SSL > >> routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid argument > >> relay_dispatch_ca: privenc result after timeout > >> > > TLSv1 and TSLv1.1 are disabled by default, and you must enable them to use > > them; see man for relayd.conf. > > not just disabled, in july 2023 tls 1.0 and 1.1 were completely removed from > libtls, and very shortly later also from libssl. > > (plus the Gemini specification actually requires tls 1.2 or 1.3) > This error looks more like something to do with a cert than with the TLS version.
Re: relayd TLS handshake failure
On 21/08/24 14:49, Kirill A. Korinsky wrote: > On Wed, 21 Aug 2024 14:32:34 +0200, > David McMackins II wrote: >> rsae_send_imsg: privenc poll timeout, keyop #0 >> relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS >> handshake error: handshake failed: error:1402D438:SSL >> routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid argument >> relay_dispatch_ca: privenc result after timeout >> > TLSv1 and TSLv1.1 are disabled by default, and you must enable them to use > them; see man for relayd.conf. not just disabled, in july 2023 tls 1.0 and 1.1 were completely removed from libtls, and very shortly later also from libssl. (plus the Gemini specification actually requires tls 1.2 or 1.3)
Re: relayd TLS handshake failure
Hi David,
I run vger 2.0.1 on amd64 as written by solene.
my relayd.conf looks like yours
cat /etc/relayd.conf
log connection
tcp protocol "gemini" {
tls keypair
}
relay "gemini" {
listen on port 1965 tls
protocol "gemini"
forward to 127.0.0.1 port 8965
}
I also use the acme-client to create/update the cert.
cat /etc/acme-client.conf
domain {
alternative names { }
domain key "/etc/ssl/private/.key"
domain certificate "/etc/ssl/.pem"
domain full chain certificate
"/etc/ssl/.fullchain.pem"
sign with letsencrypt
}
And I also created the symlink for the certificate
/etc/ssl/.crt -> .pem
I don't have any problems with this setup.
Best regards,
Sven
On 8/21/24 15:25, David McMackins II wrote:
Thanks. I should have mentioned I did already try adding the "tls
tlsv1" directive in the gemini protocol section and it yielded the same
result, so I removed it before opening this thread.
Re: relayd TLS handshake failure
On Wed, Aug 21, 2024 at 07:32:34AM GMT, David McMackins II wrote:
> Hello.
>
> I'm trying to set up a gemini server using vger and following the
> instructions in its git repo: https://tildegit.org/solene/vger
>
> However, the TLS handshake with relayd is failing as follows:
>
> rsae_send_imsg: privenc poll timeout, keyop #0
> relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS
> handshake error: handshake failed: error:1402D438:SSL
> routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid argument
> relay_dispatch_ca: privenc result after timeout
>
> I reached out to the vger developer first, and there doesn't appear to
> be anything wrong with my relayd config:
>
> log connection
>
> tcp protocol "gemini" {
> tls keypair retro.inetcc.org
> }
>
> relay "gemini" {
> listen on retro.inetcc.org port 1965 tls
> protocol "gemini"
> forward to 127.0.0.1 port 11965
> }
>
>
> My TLS cert/key were generated using acme-client, and I made a symlink
> for relayd to find the certificate since the default name from acme-
> client is not what relayd is expecting.
>
> I'm wondering if this is actually a bug specific to sparc64 which I'm
> running this on.
Wild guesses that usually bite me with relayd:
- if my memory serves me right, relayd only supports RSA keys. If you
added "ecdsa" to your acme-client.conf, then that's not going to fly.
- double-check that you linked the fullchain, not the only the leaf
cert.
Re: relayd TLS handshake failure
Thanks. I should have mentioned I did already try adding the "tls tlsv1" directive in the gemini protocol section and it yielded the same result, so I removed it before opening this thread. -- Regards, David E. McMackins II www.mcmackins.org On Wed, 2024-08-21 at 14:49 +0200, Kirill A.Korinsky wrote: > On Wed, 21 Aug 2024 14:32:34 +0200, > David McMackins II wrote: > > > > rsae_send_imsg: privenc poll timeout, keyop #0 > > relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS > > handshake error: handshake failed: error:1402D438:SSL > > routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid > > argument > > relay_dispatch_ca: privenc result after timeout > > > > TLSv1 and TSLv1.1 are disabled by default, and you must enable them > to use > them; see man for relayd.conf. >
Re: relayd TLS handshake failure
On Wed, 21 Aug 2024 14:32:34 +0200, David McMackins II wrote: > > rsae_send_imsg: privenc poll timeout, keyop #0 > relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS > handshake error: handshake failed: error:1402D438:SSL > routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid argument > relay_dispatch_ca: privenc result after timeout > TLSv1 and TSLv1.1 are disabled by default, and you must enable them to use them; see man for relayd.conf. -- wbr, Kirill
relayd TLS handshake failure
Hello.
I'm trying to set up a gemini server using vger and following the
instructions in its git repo: https://tildegit.org/solene/vger
However, the TLS handshake with relayd is failing as follows:
rsae_send_imsg: privenc poll timeout, keyop #0
relay gemini, session 1 (1 active), 0, 192.168.1.1 -> :11965, TLS
handshake error: handshake failed: error:1402D438:SSL
routines:ACCEPT_SW_CERT:tlsv1 alert internal error: Invalid argument
relay_dispatch_ca: privenc result after timeout
I reached out to the vger developer first, and there doesn't appear to
be anything wrong with my relayd config:
log connection
tcp protocol "gemini" {
tls keypair retro.inetcc.org
}
relay "gemini" {
listen on retro.inetcc.org port 1965 tls
protocol "gemini"
forward to 127.0.0.1 port 11965
}
My TLS cert/key were generated using acme-client, and I made a symlink
for relayd to find the certificate since the default name from acme-
client is not what relayd is expecting.
I'm wondering if this is actually a bug specific to sparc64 which I'm
running this on.
--
Regards,
David E. McMackins II
www.mcmackins.org
