imap.somethingofficial.test/ssl/user=[email protected] (faked) worked and works, but localhost/novalidate-cert/ssl/user=localuser (only faked
user) does not.
On Fri, 21 Jan 2022, Başar Alabay wrote:
imap.somethingofficial.test/ssl/user=[email protected] (faked) worked and
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
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
[-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 31 Zeilen --]
On Mon, 24 Jan 2022, Başar Alabay wrote:
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
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)
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.
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.
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.
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.
Başar Alabay wrote:
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.
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.
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.
[-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 19 Zeilen --]
On Tue, 25 Jan 2022, Başar Alabay wrote:
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.
That was included, all the years through:
name.of.machine/novalidate-cert/secure/user=name
[-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 13 Zeilen --]
On Wed, 26 Jan 2022, Başar Alabay wrote:
That was included, all the years through:
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.
[-- text/plain, Encoding quoted-printable, Zeichensatz: ISO-8859-2, 32 Zeilen --]
On Thu, 27 Jan 2022, Başar Alabay wrote:
/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.
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 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.
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?!
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 46:35:08 |
| Calls: | 12,112 |
| Calls today: | 3 |
| Files: | 15,010 |
| Messages: | 6,518,487 |