Folder collections, local server, ssl

[Başar Alabay]

I occasionally use alpine to check my mails from my hosters imap
account. That works. For that account I also have a folder collection,
that works, too. Though alpine often claims while starting up, that it
cannot find folder x, folder y etc. But later on, it seems to find them.

But I also had a folder collection with folders on my local imap server.
I think I remember that this worked for years, but recently there was a
big change in ssl and ssh. Maybe (?) after this backup the connection to
my localhost seems not to work anymore.

imap.somethingofficial.test/ssl/user=***@server.test (faked) worked and
works, but localhost/novalidate-cert/ssl/user=localuser (only faked
user) does not. I tried localhost/novalidate-cert/secure/user=localuser,
and that doesn’t work either. No route to host. Just tested … sending
does not work either. And this worked for yeras. Now it says SSL
negotiation failed. Using OpenSSH_8.8p1, OpenSSL 3.0.1 14 Dec 2021. What
could be the problem?

B. Alabay

[Eduardo Chappa]

Post by Başar Alabay
works, but localhost/novalidate-cert/ssl/user=localuser (only faked
user) does not.

Are you running Alpine in a unix/linux machine?

If so, what is the output of the command

openssl s_client -connect localhost:993 -crlf

[Başar Alabay]

Post by Eduardo Chappa

Post by Başar Alabay
works, but localhost/novalidate-cert/ssl/user=localuser (only faked
user) does not.

Are you running Alpine in a unix/linux machine?
If so, what is the output of the command
openssl s_client -connect localhost:993 -crlf

Lots of informations, and this:

verify error:num=18:self-signed certificate
verify return:1

00B02374FF7F0000:error:0A0C0103:SSL
routines:tls_process_key_exchange:internal
error:ssl/statem/statem_clnt.c:2247:

Verification error: self-signed certificate

B. Alabay

[Eduardo Chappa]

Post by Eduardo Chappa
Are you running Alpine in a unix/linux machine?
If so, what is the output of the command
openssl s_client -connect localhost:993 -crlf

verify error:num=18:self-signed certificate verify return:1
00B02374FF7F0000:error:0A0C0103:SSL
routines:tls_process_key_exchange:internal
Verification error: self-signed certificate

The error that you are seeing in Alpine is not this. The error you are
seeing in Alpine is that you are not connected to the internet. What is
the result of running the command

uname -n

in your system, and what happens when you use the value given by that
command instead of "localhost" (assuming these values are different)

[Başar Alabay]

[-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 31 Zeilen --]

Post by Eduardo Chappa
Are you running Alpine in a unix/linux machine?
If so, what is the output of the command
openssl s_client -connect localhost:993 -crlf

verify error:num=18:self-signed certificate verify return:1
00B02374FF7F0000:error:0A0C0103:SSL
routines:tls_process_key_exchange:internal
Verification error: self-signed certificate

The error that you are seeing in Alpine is not this. The error you are
seeing in Alpine is that you are not connected to the internet. What is
the result of running the command
uname -n

Then I see a hostname that is internal.

in your system, and what happens when you use the value given by that
command instead of "localhost" (assuming these values are different)

Oh, I don’t think that this would work, because it never was intended to
reach the machine via outside. Usually I can reach everything with
localhost or the lan name of the machine. This worked with alpie, too. I
don’t know if an update of alpine broke that or an update of ssh/ssl.

B. Alabay

[Başar Alabay]

Post by Başar Alabay

Post by Eduardo Chappa
uname -n

Then I see a hostname that is internal.

Post by Eduardo Chappa
in your system, and what happens when you use the value given by that
command instead of "localhost" (assuming these values are different)

Oh, I don’t think that this would work, because it never was intended to
reach the machine via outside. Usually I can reach everything with
localhost or the lan name of the machine. This worked with alpie, too. I
don’t know if an update of alpine broke that or an update of ssh/ssl.

Nevertheless I tried that – uname -n gives a router given name. The same
happens: Alpines UI gets overwritten by the statement that the
authenticity of the host can't be established … the host key is known by
the following other name/address localhost, continue connecting
yes/no/fingerprint. This is overwriting, so I cannot react.

B. Alabay

[Başar Alabay]

Post by Başar Alabay

Post by Başar Alabay

Post by Eduardo Chappa
uname -n

Then I see a hostname that is internal.

Post by Eduardo Chappa
in your system, and what happens when you use the value given by that
command instead of "localhost" (assuming these values are different)

Oh, I don’t think that this would work, because it never was intended to
reach the machine via outside. Usually I can reach everything with
localhost or the lan name of the machine. This worked with alpie, too. I
don’t know if an update of alpine broke that or an update of ssh/ssl.

Nevertheless I tried that – uname -n gives a router given name. The same
happens: Alpines UI gets overwritten by the statement that the
authenticity of the host can't be established … the host key is known by
the following other name/address localhost, continue connecting
yes/no/fingerprint. This is overwriting, so I cannot react.

I’ve made a manual ssh … so this is done. And now alpine says again
connection failed to xyz,143: connection refused.

xyz is faked.

B. Alabay

[Eduardo Chappa]

I’ve made a manual ssh 
 so this is done. And now alpine says again
connection failed to xyz,143: connection refused.
xyz is faked.

the "connection refused" error means that the server that you are trying
to connect is not listening in port 143. Maybe these errors can be
explained by a configuration of your router that is not forwarding this
connections to the correct computer that is actually listening in that
port.

[Başar Alabay]

[-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 19 Zeilen --]

Post by Başar Alabay
I’ve made a manual ssh … so this is done. And now alpine says again
connection failed to xyz,143: connection refused.
xyz is faked.

the "connection refused" error means that the server that you are trying
to connect is not listening in port 143. Maybe these errors can be
explained by a configuration of your router that is not forwarding this
connections to the correct computer that is actually listening in that
port.

Hm, all this is local on the machine. I thought, localhost does not make
the loop via the whole network?

B. Alabay

[Eduardo Chappa]

Post by Başar Alabay

Post by Eduardo Chappa
uname -n

Then I see a hostname that is internal.

Post by Eduardo Chappa
in your system, and what happens when you use the value given by that
command instead of "localhost" (assuming these values are different)

Oh, I don’t think that this would work, because it never was intended to
reach the machine via outside. Usually I can reach everything with
localhost or the lan name of the machine. This worked with alpie, too. I
don’t know if an update of alpine broke that or an update of ssh/ssl.

Nevertheless I tried that – uname -n gives a router given name. The same
happens: Alpines UI gets overwritten by the statement that the
authenticity of the host can't be established 
 the host key is known by
the following other name/address localhost, continue connecting
yes/no/fingerprint. This is overwriting, so I cannot react.

I am confused. Originally you said that the error was "no route to host"
which is an error that is given when you do not have an internet
connection. Now the error is different, and it is about a self-signed
certificate, wich was also given to you by openssl. In order to avoid this
error you can add /novalidate-cert to the definition of your server.

[Başar Alabay]

Post by Eduardo Chappa

Post by Başar Alabay
Nevertheless I tried that – uname -n gives a router given name. The same
happens: Alpines UI gets overwritten by the statement that the
authenticity of the host can't be established … the host key is known by
the following other name/address localhost, continue connecting
yes/no/fingerprint. This is overwriting, so I cannot react.

I am confused. Originally you said that the error was "no route to host"
which is an error that is given when you do not have an internet
connection. Now the error is different, and it is about a self-signed
certificate, wich was also given to you by openssl. In order to avoid this
error you can add /novalidate-cert to the definition of your server.

That was included, all the years through:

name.of.machine/novalidate-cert/secure/user=name

name.of.machine was localhost in the beginning. And secure was ssl or
tls, I fotgot that, the years before.

Mail.app can connect to the local (dovecot) server.

B. Alabay

[Eduardo Chappa]

Post by Başar Alabay
name.of.machine/novalidate-cert/secure/user=name

/secure does not do what you think it does. Try /ssl or /tls as
appropriate.

[Başar Alabay]

[-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 13 Zeilen --]

Post by Başar Alabay
name.of.machine/novalidate-cert/secure/user=name

/secure does not do what you think it does. Try /ssl or /tls as
appropriate.

/ssl gives a big note, that this will not work, I shall use /notls. With
/notls Alpine can't connect and has (again) this overwriting asking for
a password. And with /tls connection refused. Very, very strange. This
was not this way before.

B. Alabay

[Eduardo Chappa]

Post by Başar Alabay
/ssl gives a big note, that this will not work, I shall use /notls. With
/notls Alpine can't connect and has (again) this overwriting asking for
a password. And with /tls connection refused. Very, very strange. This
was not this way before.

One way in which the openssl could be failing is that your server and
Alpine support different encryption protocols. Try seeing if compiling
Alpine by yourself solves the problem, or if upgrading your dovecot will
help.

In regards to "overwriting asking for a password" i am not sure exactly
what you mean. My interpretation of that is that Alpine is trying rsh and
this is failing. This is typically because there is an error in a .login
file (~/.bashrc maybe?) and when an error is found the password is
requested (one way to test this is to simply rename the ~/.bashrc file and
see if asking for a password goes away. If that is the case, work in
fixing your ~/.bashrc file.)

Finally, as I implied before, you have to open port 143 if you want to use
/tls. Otherwise the connection will be refused.

[Başar Alabay]

[-- text/plain, Encoding quoted-printable, Zeichensatz: ISO-8859-2, 32 Zeilen --]

Post by Başar Alabay
/ssl gives a big note, that this will not work, I shall use /notls. With
/notls Alpine can't connect and has (again) this overwriting asking for
a password. And with /tls connection refused. Very, very strange. This
was not this way before.

One way in which the openssl could be failing is that your server and
Alpine support different encryption protocols. Try seeing if compiling
Alpine by yourself solves the problem, or if upgrading your dovecot will
help.

My dovecot ist part of Cutedge, so I can’t update that. It’s a server
package. Alpine is taken from Macports. Is that self compiling enough?

In regards to "overwriting asking for a password" i am not sure exactly
what you mean. My interpretation of that is that Alpine is trying rsh and
this is failing. This is typically because there is an error in a .login
file (~/.bashrc maybe?) and when an error is found the password is
requested (one way to test this is to simply rename the ~/.bashrc file and
see if asking for a password goes away. If that is the case, work in
fixing your ~/.bashrc file.)

I use zsh with oh-my-zsh. With »overwriting« I mean, that it is like
a draw error – alpine gets overdrawn with the prompt, but I cannot type
anything. I’ve never seen that before.

Finally, as I implied before, you have to open port 143 if you want to use
/tls. Otherwise the connection will be refused.

Where do I have to open that? Alpine runs locally on the machine where
it shall open the folders with the password of the user. All this worked
before, I didn’t change anything … except ssh/ssl updates and alpine
updates. Nothing was opened, nothing closed?!

B. Alabay

[Eduardo Chappa]

My dovecot ist part of Cutedge, so I can’t update that. It’s a server
package. Alpine is taken from Macports. Is that self compiling enough?

I have no idea. The point I am trying to make is that if you do not
control this, you can get into trouble. I do not know what versions of
openssl were used to compile your software. I do not know if you have a
configuration file for openssl that is involved here, and in general I do
not know much about your system. All I know is that you have a mac, with
no idea of what version you are running, or versions of the software that
is being run there. You can ignore my previous comment and reply with
generic answers like the one above, but all I can tell you is that you are
addressing the issue by not investigating. I am telling what to look at,
please take a deep look into that.

I use zsh with oh-my-zsh. With »overwriting« I mean, that it is like a
draw error – alpine gets overdrawn with the prompt, but I cannot type
anything. I’ve never seen that before.

So, as I said, investigate the ".login" file that the zsh shell has. I do
not use zsh, or know what is the default. All I can tell you is what I
think you should investigate, but I cannot investigate it for you in your
system.

Where do I have to open that? Alpine runs locally on the machine where
it shall open the folders with the password of the user. All this worked
before, I didn’t change anything 
 except ssh/ssl updates and alpine
updates. Nothing was opened, nothing closed?!

Since I do not own a mac, I do not know the answer to that so I would
suggest you ask that question in a list that is appropriate for that,
unless someone here knows how to do that and wants to tell us how to do
that. Otherwise, there is always a search engine that might answer that
question for you.

Have fun investigating!