Fetchmail werkt niet meer

[tjoen]

Sinds nieuwe fetchmail 6.4.38. Vorige was 6.4.34

$ fetchmail
fetchmail: Server certificate verification error: self-signed
certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
in the trusted CA certificate location, or that c_rehash needs to be
run on the certificate directory. For details, please see the
documentation of --sslcertpath and --sslcertfile in the manual page.
See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
verify failed
fetchmail: pop3.dds.nl: upgrade to TLS failed.
fetchmail: Socket or TLS error on ***@pop3.dds.nl
fetchmail: socket error while fetching from ***@pop3.dds.nl
fetchmail: Query status=2 (SOCKET)

nss geupgrade naar 3.98
Zelfde fetchmail probleem, downgrade naar 6.4.34 idem
Kan helaas niet nss downgraden omdat ik de rpm kwijt ben

/etc/ssl/certs/ca-certificates.crt
is leeg (alleen comments)

Thunderbird naar mijn popaccount werkt wel

Waar zit het probleem? pop3-server? fetchmail? nss?

[Roger]

Post by tjoen
Sinds nieuwe fetchmail 6.4.38. Vorige was 6.4.34
$ fetchmail
fetchmail: Server certificate verification error: self-signed
 certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
 Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
 Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
 in the trusted CA certificate location, or that c_rehash needs to be
 run on the certificate directory. For details, please see the
 documentation of --sslcertpath and --sslcertfile in the manual page.
 See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
 verify failed
fetchmail: pop3.dds.nl: upgrade to TLS failed.
fetchmail: Query status=2 (SOCKET)
nss geupgrade naar 3.98
Zelfde fetchmail probleem, downgrade naar 6.4.34 idem
Kan helaas niet nss downgraden omdat ik de rpm kwijt ben
/etc/ssl/certs/ca-certificates.crt
is leeg (alleen comments)
Thunderbird naar mijn popaccount werkt wel
Waar zit het probleem? pop3-server? fetchmail? nss?

De certificate chain van pop3.dds.nl is OK ('openssl s_client -showcerts
-connect pop3.dds.nl:110 -starttls pop3' ==> 'Verification: OK').

Het probleem zit op de machine waarop je fetchmail draait: het root certificaat
(van USERTrust RSA Certification Authority) is onbekend in de trusted root cache.
Het certificaat is een root certificaat (self signed), maar niet trusted. Zie de
2e en 3e melding van fetchmail. Een mogelijke remedie staat ook in de 3e melding.

Thunderbird heeft zijn eigen trusted root cache en heeft daardoor geen last
van dit probleem.

Groeten,
-Roger

[tjoen]

...

Post by Roger

Post by tjoen
fetchmail: Server certificate verification error: self-signed
  certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
  Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
  Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
  in the trusted CA certificate location, or that c_rehash needs to be
  run on the certificate directory. For details, please see the
  documentation of --sslcertpath and --sslcertfile in the manual page.
  See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
  verify failed

...

Post by Roger
Het probleem zit op de machine waarop je fetchmail draait: het root certificaat
(van USERTrust RSA Certification Authority) is onbekend in de trusted root cache.
Het certificaat is een root certificaat (self signed), maar niet trusted. Zie de
2e en 3e melding van fetchmail. Een mogelijke remedie staat ook in de 3e melding.

Ik denk dat je mij heel goed hebt geholpen. Dank!
Als ik het goed heb begerepen moet cert in
/etc/ssl/certs/ca-certificates.crt

Er is een SSL-Certificates-HOWTO
Ik hoop dat daar stapsgewijze handelingen worden beschreven

Nogmaals bedankt voor de uitleg!

[Richard Lucassen]

On Wed, 28 Feb 2024 19:27:43 +0100

Post by tjoen
Ik denk dat je mij heel goed hebt geholpen. Dank!
Als ik het goed heb begerepen moet cert in
/etc/ssl/certs/ca-certificates.crt
Er is een SSL-Certificates-HOWTO
Ik hoop dat daar stapsgewijze handelingen worden beschreven

Ik neem aan dat je met RedHat o.i.d. werkt? Want bij Debian is dat een
onderdeel van het package ca-certificates, daar zitten alle trusted
root ca's in. Is dat pakket wel goed geinstalleerd? Want die
file /etc/ssl/certs/ca-certificates.crt bevat alle root ca's en in
diezelfde dir staan symlinks naar de losse root ca's die ergens
in /usr/share/ rondhangen.

Misschien is het voldoende om "yum install ca-certificates" te runnen,
geen idee, heb al jaren niet meer met RH/CentOS gewerkt

R.

[tjoen]

Post by Richard Lucassen
On Wed, 28 Feb 2024 19:27:43 +0100

Post by tjoen
Ik denk dat je mij heel goed hebt geholpen. Dank!
Als ik het goed heb begerepen moet cert in
/etc/ssl/certs/ca-certificates.crt
Er is een SSL-Certificates-HOWTO
Ik hoop dat daar stapsgewijze handelingen worden beschreven

Ik neem aan dat je met RedHat o.i.d. werkt?

Het is een BLFS (B = beyond)
..

Post by Richard Lucassen
Want die
file /etc/ssl/certs/ca-certificates.crt bevat alle root ca's en in
diezelfde dir staan symlinks naar de losse root ca's die ergens
in /usr/share/ rondhangen.

Vlgs documentaties zou Mozilla ze hebben in nss
Met www.mail-archive.com/modssl-***@modssl.org/msg16980.html
zouden die aangemmakt worden

Post by Richard Lucassen
Misschien is het voldoende om "yum install ca-certificates" te runnen,
geen idee, heb al jaren niet meer met RH/CentOS gewerkt

I zou eeen RPM of DPKG van distros kunnen installeren
maar eerst verdiepen in SSL-Cert HOWTO en kijken hoe BLFS
het heeft gedaan.

Dank voor het meedenken. en als het lukt of niet meld ik het

[tjoen]

On 2/28/24 21:30, Richard Lucassen wrote:
...

Post by Richard Lucassen
Misschien is het voldoende om "yum install ca-certificates" te runnen,

...

nss is veranderd: de certs zitten gebakken in libnssckbi.so
Self signed certs worden niet gezien

Om dat te wijzigen moet die van p11-kit gebruikt worden.
./configure zet die default in
/etc/ssl/certs/ca-certificates.crt
Deze is momenteel leeg, alleen een comment

Ik weet alleen niet of die defauls wel de beste methode is

[Richard Lucassen]

On Thu, 29 Feb 2024 18:54:12 +0100

Post by tjoen
Om dat te wijzigen moet die van p11-kit gebruikt worden.
./configure zet die default in
/etc/ssl/certs/ca-certificates.crt
Deze is momenteel leeg, alleen een comment
Ik weet alleen niet of die defauls wel de beste methode is

Ik kan die Debian file wel in je mailbox gooien als je wilt

[tjoen]

Post by Richard Lucassen
Ik kan die Debian file wel in je mailbox gooien als je wilt

Dank voor het aanbod.
Maar ik kan de nieuwste zel opkalen bij cacert.org.
Ik zit nog te denken over de locatie waar die moet zetten.
/etc/ssl/certs/ca-certificates.crt is mogelijk niet de default

[Richard Lucassen]

On Fri, 1 Mar 2024 09:47:57 +0100

Post by tjoen

Post by Richard Lucassen
Ik kan die Debian file wel in je mailbox gooien als je wilt

Dank voor het aanbod.
Maar ik kan de nieuwste zel opkalen bij cacert.org.
Ik zit nog te denken over de locatie waar die moet zetten.
/etc/ssl/certs/ca-certificates.crt is mogelijk niet de default

Bij Debian (en kennelijk bij RH) in ieder geval wel

R.

[tjoen]

Post by Richard Lucassen
On Fri, 1 Mar 2024 09:47:57 +0100

...

Post by Richard Lucassen

Post by tjoen
Ik zit nog te denken over de locatie waar die moet zetten.
/etc/ssl/certs/ca-certificates.crt is mogelijk niet de default

Bij Debian (en kennelijk bij RH) in ieder geval wel

./configure van fetchmail zoekt eerst in /etc/pki/
Indien gevonden dan wordt die gebruikt i.p.v die in /etc/ssl/
Eigenaardig.

Heb ook ontdekt dat fetchmail niet van nss gebruik maakt.
Mogelijk met ik dus alleen openssl.cnf configureren
Vreemd dat het altijd gewerkt heeft tot upgrades nss etc.

[Roger]

Post by tjoen
...

Post by Richard Lucassen
Misschien is het voldoende om "yum install ca-certificates" te runnen,

...
nss is veranderd: de certs zitten gebakken in libnssckbi.so
Self signed certs worden niet gezien

Hoe bedoel je? Dat een certificaat self signed is (Issuer == Subject) is de
definitie van een root certificaat. De crux is dat zo'n certificaat ook moet
worden vertrouwd om als Trust Anchor te kunnen fungeren (dwz. als begin van
een geldige certificate chain). Daarvoor moet het root certificaat zijn
opgenomen in de trusted root cache van systeem of applicatie.

'USERTrust RSA Certification Authority' is een zeer bekende Root CA die in
elke up-to-date trusted root cache hoort te zitten.

Dat een root certificaat in libnssckbi.so zit, is niet voldoende om een
trusted root certificaat zijn. Daarvoor moet ook de bijbehorende trust flag
in cert8.db zijn gezet (zie https://wiki.mozilla.org/NSS:Root_certs).

Post by tjoen
Om dat te wijzigen moet die van p11-kit gebruikt worden.
./configure zet die default in
/etc/ssl/certs/ca-certificates.crt
Deze is momenteel leeg, alleen een comment

Als die file voorheen de trusted root certificaten bevatte en nu leeg is,
dan zou dat het probleem verklaren. Heb je je fetchmail configuratie al
eens gecontroleerd? (eventuele sslcertfile optie)

Groeten,
-Roger

[tjoen]

On 3/1/24 10:38, Roger wrote:
....

Post by Roger
Hoe bedoel je? Dat een certificaat self signed is (Issuer == Subject) is de
definitie van een root certificaat. De crux is dat zo'n certificaat ook moet
worden vertrouwd om als Trust Anchor te kunnen fungeren (dwz. als begin van
een geldige certificate chain). Daarvoor moet het root certificaat zijn
opgenomen in de trusted root cache van systeem of applicatie.
'USERTrust RSA Certification Authority' is een zeer bekende Root CA die in
elke up-to-date trusted root cache hoort te zitten.
Dat een root certificaat in libnssckbi.so zit, is niet voldoende om een
trusted root certificaat zijn. Daarvoor moet ook de bijbehorende trust flag
in cert8.db zijn gezet (zie https://wiki.mozilla.org/NSS:Root_certs).

Openssl is voor mij ingewikkelder dan ik gedacht heb.
Die libnssckb.so bevat die van Mozilla

Ik zit nu te zoeken waar systeem de certs zit te zoeken
Nooit eerder probleem gehad tot fetchmail het niet meer deed

Post by Roger

Post by tjoen
Om dat te wijzigen moet die van p11-kit gebruikt worden.
./configure zet die default in
/etc/ssl/certs/ca-certificates.crt
Deze is momenteel leeg, alleen een comment

Als die file voorheen de trusted root certificaten bevatte en nu leeg is,
dan zou dat het probleem verklaren. Heb je je fetchmail configuratie al
eens gecontroleerd? (eventuele sslcertfile optie)

Ik geloof dat vorgaande versie wel inhoud had maar kan dat niet meer
bevestigen.
Ik ga eerst die p11-kit opnieuw bouwen met trysted cert op eerste
locatie die gezocht wordt

[tjoen]

Post by tjoen
Sinds nieuwe fetchmail 6.4.38. Vorige was 6.4.34

mk-ca-bundle.pl geeft alleen fouten ondanks aanwezigheid
alle tien dependencies.
Mogelik dat daarom BLFS er een shelscript van heeft gemaakt.
# make-ca is een ramp: alles in /etc/ssl/ verwijderd
en alles in /etc/pki/anchors/ gezet.
openssl opnieuw gebouwd met --openssldir=/etc/pki/tls/
dovecot probeem: /ec/ssl/certs is nu symlink naar
/etc/pki/tls/certs/

Post by tjoen
$ fetchmail
fetchmail: Server certificate verification error: self-signed
 certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
 Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
 Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
 in the trusted CA certificate location, or that c_rehash needs to be
 run on the certificate directory. For details, please see the
 documentation of --sslcertpath and --sslcertfile in the manual page.
 See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
 verify failed
fetchmail: pop3.dds.nl: upgrade to TLS failed.
fetchmail: Query status=2 (SOCKET)

Fout bleef bestaan. Toch server probleem
Opgelost met
$ fetchmail --nosslcertck
Maar zou onveilig zijn zonder --sslfingerprint
Maar die krijg ik niet met
$ fetchmail -v
zoals documentatie zegt

Zijn username + passwd nou wwel of niet versleuteld?

[Roger]

Post by tjoen

Post by tjoen
Sinds nieuwe fetchmail 6.4.38. Vorige was 6.4.34

mk-ca-bundle.pl geeft alleen fouten ondanks aanwezigheid
alle tien dependencies.
Mogelik dat daarom BLFS er een shelscript van heeft gemaakt.
# make-ca is een ramp: alles in /etc/ssl/ verwijderd
en alles in /etc/pki/anchors/ gezet.
openssl opnieuw gebouwd met --openssldir=/etc/pki/tls/
dovecot probeem: /ec/ssl/certs is nu symlink naar
/etc/pki/tls/certs/

Post by tjoen
$ fetchmail
fetchmail: Server certificate verification error: self-signed
  certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
  Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
  Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
  in the trusted CA certificate location, or that c_rehash needs to be
  run on the certificate directory. For details, please see the
  documentation of --sslcertpath and --sslcertfile in the manual page.
  See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
  verify failed
fetchmail: pop3.dds.nl: upgrade to TLS failed.
fetchmail: Query status=2 (SOCKET)

Fout bleef bestaan. Toch server probleem
Opgelost met
$ fetchmail --nosslcertck

Niet opgelost maar genegeerd. Je koopt tijd ten koste van veiligheid.

Post by tjoen
Maar zou onveilig zijn zonder --sslfingerprint
Maar die krijg ik niet met
$ fetchmail -v
zoals documentatie zegt

De documentatie zeg bij -v niets over de fingerprint. Je zou -v -v
kunnen proberen voor meer detail.

De documentatie zegt wel:

To obtain the fingerprint of a certificate stored in the file
cert.pem, try:

openssl x509 -in cert.pem -noout -md5 -fingerprint

Post by tjoen
Zijn username + passwd nou wwel of niet versleuteld?

Die zijn nog steeds versleuteld. Maar doordat de geldigheid van het
certificaat geen voorwaarde meer is voor een succesvolle connectie
ben je zonder --sslfingerprint open voor MITM aanvallen.

Het gebruik van --sslfingerprint heeft als nadeel dat je de fingerprint
elke keer moet aanpassen als de mailserver het certificaat vernieuwt.

Groeten,
-Roger

[Roger]

Post by Roger
Die zijn nog steeds versleuteld.

Dit blijkt niet te kloppen :( Ik had even een uurtje en heb eens een blik
geworpen op de source code.

--nosslcertck heeft i.c.m. STARTTLS tot gevolg dat helemaal geen TLS/SSL wordt
gebruikt. Daarom zie je de fingerprint ook niet in de -v output. Het gedrag is
dus anders als wat de documentatie zegt. Dat is kwalijk.

Probeer eens --sslfingerprint met een dummy fingerprint (bv. allemaal nullen).
Dan zou je de juiste fingerprint moeten zien in de output.

Groeten,
-Roger

[tjoen]

On 3/12/24 12:46, Roger wrote:
...

Post by Roger
--nosslcertck heeft i.c.m. STARTTLS tot gevolg dat helemaal geen TLS/SSL wordt
gebruikt. Daarom zie je de fingerprint ook niet in de -v output. Het gedrag is
dus anders als wat de documentatie zegt. Dat is kwalijk.

Onversleuteld dus? Ook inloggen met username + passwd?

Post by Roger
Probeer eens --sslfingerprint met een dummy fingerprint (bv. allemaal nullen).

Geprobeerd, resultaat = geen fingerprint

[Roger]

Post by tjoen
...

Post by Roger
--nosslcertck heeft i.c.m. STARTTLS tot gevolg dat helemaal geen TLS/SSL wordt
gebruikt. Daarom zie je de fingerprint ook niet in de -v output. Het gedrag is
dus anders als wat de documentatie zegt. Dat is kwalijk.

Onversleuteld dus? Ook inloggen met username + passwd?

Voor zover ik vanuit de source kan zien: inderdaad.

Post by tjoen

Post by Roger
Probeer eens --sslfingerprint met een dummy fingerprint (bv. allemaal nullen).

Geprobeerd, resultaat = geen fingerprint

Vreemd. Je doet grosso modo dit, neem ik aan:
fetchmail -v --nosslcertck --sslfingerprint 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Post eens commando en output van wat je doet (zonder usernames of passwords).

Groeten,
-Roger

[tjoen]

On 3/12/24 19:31, Roger wrote:
...

Post by Roger

Post by tjoen

Post by Roger
Probeer eens --sslfingerprint met een dummy fingerprint (bv. allemaal nullen).

Geprobeerd, resultaat = geen fingerprint

fetchmail -v --nosslcertck --sslfingerprint
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Ik zie het nu: de -v vergeten
Vlgs de FAQ voorbeeld moet die 00:00.. tussen quotes ""

Post by Roger
Post eens commando en output van wat je doet (zonder usernames of passwords).

user+ passwrds zitten bij mij in ~/.fetcmailrc
Die --nosslcertck --sslfingerprint kunnen waarschijnlijk niet
in ~/.fetchmail dus een shelscript van gemaakt

Test:
~$ bin/fetchmail
1 message for tjoen at pop3.dds.nl (2723 octets).
reading message ***@pop3.dds.nl:1 of 1 (2723 octets) flushed
You have mail in /var/mail/tdance

Het werkt! Bedankt voor de hulp

[Roger]

Post by tjoen
...

Post by Roger

Post by tjoen

Post by Roger
Probeer eens --sslfingerprint met een dummy fingerprint (bv. allemaal nullen).

Geprobeerd, resultaat = geen fingerprint

fetchmail -v --nosslcertck --sslfingerprint 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Ik zie het nu: de -v vergeten

Right...

Post by tjoen
Vlgs de FAQ voorbeeld moet die 00:00.. tussen quotes ""

De manual zegt er niets over, maar het is inderdaad een string.

De fingerprint is overigens van het certificaat, niet van de (public) key.
Dit is een fout in de fetchmail documentatie.

Post by tjoen

Post by Roger
Post eens commando en output van wat je doet (zonder usernames of passwords).

user+ passwrds zitten bij mij in ~/.fetcmailrc
Die --nosslcertck --sslfingerprint kunnen waarschijnlijk niet
in ~/.fetchmail dus een shelscript van gemaakt

Waarom denk je dat? Zie https://www.fetchmail.info/fetchmail-man.html
("Keyword: ..." info bij de betreffende optie).

"Almost all options have a corresponding keyword which can be used
to declare them in a .fetchmailrc file."

Post by tjoen
~$ bin/fetchmail
1 message for tjoen at pop3.dds.nl (2723 octets).
You have mail in /var/mail/tdance
Het werkt! Bedankt voor de hulp

Mooi. Dan kun je nu in alle rust het echte probleem oplossen (een root
certificaat dat niet wordt vertrouwd). Wat je nu hebt gemaakt faalt als
het certificaat van pop3.dds.nl wordt vernieuwd (uiterlijk 19 januari
2025).

Groeten,
-Roger

[tjoen]

On 3/12/24 20:49, Roger wrote:
...

  "Almost all options have a corresponding keyword which can be used
   to declare them in a .fetchmailrc file."

Het lijkt dat in .fetchmailrc zelfde keywords maar zonder "--" gelden

...

Mooi. Dan kun je nu in alle rust het echte probleem oplossen (een root
certificaat dat niet wordt vertrouwd). Wat je nu hebt gemaakt faalt als
het certificaat van pop3.dds.nl wordt vernieuwd (uiterlijk 19 januari
2025).

Dus provider echte cert laten maken,
Ik weet niet of ik meer kan doen

[Roger]

Post by tjoen

Post by Roger
Mooi. Dan kun je nu in alle rust het echte probleem oplossen (een root
certificaat dat niet wordt vertrouwd). Wat je nu hebt gemaakt faalt als
het certificaat van pop3.dds.nl wordt vernieuwd (uiterlijk 19 januari
2025).

Dus provider echte cert laten maken,

Welke 'provider'? De certificate chain die pop3.dds.nl presenteert is volgens
het boekje. Niets mis mee.

Post by tjoen
Ik weet niet of ik meer kan doen

Het probleem zit aan jouw kant (de trusted root cache zoals fetchmail die ziet
is niet in orde zoals ik eerder al aangaf). Het is dus primair jouw taak om dat
te verhelpen. De oorzaak kan uiteraard nog ergens anders liggen, maar dat moet
dan blijken uit de analyse.

Fetchmail gebruikt libssl (onderdeel van OpenSSL). Eerste stap is dus kijken of
OpenSSL OK is. Post eens de output van

openssl s_client -showcerts -connect pop3.dds.nl:110 -starttls pop3

Als dit goed gaat, eindigt de output met een Dovecot prompt van DDS en moet je
nog even 'quit' of CTRL-C doen om terug te keren naar je shell.

Groeten,
-Roger

[tjoen]

..

Post by Roger

Post by tjoen
Dus provider echte cert laten maken,

Welke 'provider'? De certificate chain die pop3.dds.nl presenteert is volgens
het boekje. Niets mis mee.
  openssl s_client -showcerts -connect pop3.dds.nl:110 -starttls pop3

Gaat beetje boven mijn pet:

depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network,
CN=USERTrust RSA Certification Authority
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network,
CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited,
CN=Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN=signetbreedband.nl
verify return:1
CONNECTED(00000003)

return:1 is toch niet goed?
openssl-3.2.1
Is latest stable. Moet de culprit zijn dus.

Certificate chain
0 s:CN=signetbreedband.nl
i:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited,
CN=Sectigo RSA Domain Validation Secure Server CA
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 19 00:00:00 2024 GMT; NotAfter: Jan 19 23:59:59
2025 GMT
-----BEGIN CERTIFICATE-----
..
-----END CERTIFICATE-----
1 s:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited,
CN=Sectigo RSA Domain Validation Secure Server CA
i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network,
CN=USERTrust RSA Certification Authority
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59
2030 GMT
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network,
CN=USERTrust RSA Certification Authority
i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network,
CN=USERTrust RSA Certification Authority
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Feb 1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59
2038 GMT
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=CN=signetbreedband.nl
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited,
CN=Sectigo RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5515 bytes and written 458 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
22B50DFC160A0DFB4A36E6B0D7E0CF6C53A00890E417C6B96DB7F93773C665C4
Session-ID-ctx:
Master-Key:
B4CDEF8E90A33E54B118CC8E5F28B49B8FBB4CF9F6903DED62DB7829B8C834E164EC8E5ED1B5ED415165D89A60CB267E
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 3c c3 33 ee 9e 23 75 be-13 fb e3 b1 d9 c9 4b e5
<.3..#u.......K.
0010 - 53 f5 ec 18 80 3b 98 43-3b 82 0a ad cc 18 63 22
S....;.C;.....c"
....
Start Time: 1710331519
Timeout : 7200 (sec)
Verify return code: 19 (self-signed certificate in certificate chain)
Extended master secret: no
---
+OK Dovecot ready.

[Roger]

..

Post by Roger

Post by tjoen
Dus provider echte cert laten maken,

Welke 'provider'? De certificate chain die pop3.dds.nl presenteert is volgens
het boekje. Niets mis mee.
   openssl s_client -showcerts -connect pop3.dds.nl:110 -starttls pop3

Het is nochtans behoorlijk helder.

depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA
Certification Authority
verify error:num=19:self-signed certificate in certificate chain

De laatste regel zegt (bijna) alles. OpenSSL ziet een self signed certificaat.
Dat is per definitie een root certificaat. Maar kennelijk is het geen trusted
root certificaat (dat staat helaas niet in de foutmelding). Daardoor zijn alle
certificaten in de certificate chain niet trusted.

Op zichzelf is deze foutmelding gunstig: ze maakt het waarschijnlijk dat je
probleem met fetchmail wordt veroorzaakt door een probleem met OpenSSL. Dat
maakt de kans groot dat je beide problemen in één keer kunt oplossen.

verify return:1
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA
Certification Authority
verify return:1
depth=1 C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain
Validation Secure Server CA
verify return:1
depth=0 CN=signetbreedband.nl
verify return:1
CONNECTED(00000003)
return:1 is toch niet goed?

Dat zou je denken, maar dat blijkt hier niet het geval. Ik zie bij mij ook 'return:1',
maar bij mij klaagt OpenSSL niet over een self signed certificaat.

openssl-3.2.1
Is latest stable. Moet de culprit zijn dus.

Daarvoor is (nog) geen bewijs. Conclusies trek je pas aan het eind.

Certificate chain
 0 s:CN=signetbreedband.nl
   i:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain
Validation Secure Server CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 19 00:00:00 2024 GMT; NotAfter: Jan 19 23:59:59 2025 GMT
-----BEGIN CERTIFICATE-----
..
-----END CERTIFICATE-----
 1 s:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain
Validation Secure Server CA
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA
Certification Authority
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA
Certification Authority
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA
Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Feb  1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=CN=signetbreedband.nl
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain
Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 5515 bytes and written 458 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 22B50DFC160A0DFB4A36E6B0D7E0CF6C53A00890E417C6B96DB7F93773C665C4
B4CDEF8E90A33E54B118CC8E5F28B49B8FBB4CF9F6903DED62DB7829B8C834E164EC8E5ED1B5ED415165D89A60CB267E
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    0000 - 3c c3 33 ee 9e 23 75 be-13 fb e3 b1 d9 c9 4b e5 <.3..#u.......K.
    0010 - 53 f5 ec 18 80 3b 98 43-3b 82 0a ad cc 18 63 22 S....;.C;.....c"
....
    Start Time: 1710331519
    Timeout   : 7200 (sec)
    Verify return code: 19 (self-signed certificate in certificate chain)
    Extended master secret: no
---
+OK Dovecot ready.

De grote vraag is waarom het root certificaat niet trusted is.

OpenSSL verwacht de trusted root certificaten in '$(OPENSSLDIR)/certs'. De
waarde van OPENSSLDIR krijg je te zien met 'openssl version -d'.

==> Wat is de output van 'openssl version -d' ?

==> Staan er certificaten in de certs subdirectory van OPENSSLDIR? Of is de
certs directory leeg? (NB. 'certs' kan een link zijn naar een andere
directory. Ook de items in 'certs' kunnen weer links zijn. Dit is bv. bij
Debian het geval.)

==> Wat is de output van 'openssl version -p' ?

Groeten,
-Roger

[tjoen]

On 3/14/24 09:59, Roger wrote:
...

Post by Roger
De grote vraag is waarom het root certificaat niet trusted is.

Moet ik zelf ook een trusted certificaat hebben of geldt dat alleen voor
de mailserver?

Post by Roger
OpenSSL verwacht de trusted root certificaten in '$(OPENSSLDIR)/certs'. De
waarde van OPENSSLDIR krijg je te zien met 'openssl version -d'.
==> Wat is de output van 'openssl version -d' ?

OPENSSLDIR: "/etc/pki/tls"

Post by Roger
==> Staan er certificaten in de certs subdirectory van OPENSSLDIR? Of is de
    certs directory leeg? (NB. 'certs' kan een link zijn naar een andere
    directory. Ook de items in 'certs' kunnen weer links zijn. Dit is
bv. bij
    Debian het geval.)

Ik gebruikte
www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/make-ca.html
omdat mk-ca-bundle.pl alleen maar foutmelding geeft. Die zit ook in
curl.
$ ls /etc/pki/tls/certs/
ca-bundle.crt dovecot.pem objsign-ca-bundle.crt
certdata.txt email-ca-bundle.crt

ca-bundle.crt en certdata.txt zijn van nss
De andere drie waarschijnlijk gemaakt door make-ca
De rest zit in /etc/pki/anchors/ (door make-ca)

Post by Roger
==> Wat is de output van 'openssl version -p' ?

platform: linux-x86_64

[Roger]

Post by tjoen
...

Post by Roger
De grote vraag is waarom het root certificaat niet trusted is.

Moet ik zelf ook een trusted certificaat hebben of geldt dat alleen voor
de mailserver?

Enige kennis van PKI zou hier wel handig zijn (zeker als je met BLFS
werkt). Even heel in het kort (en kort door de bocht).

OpenSSL moet weten of het certificaat van de mail server kan worden
vertrouwd (dus 'trusted' is).

Het certificaat van de mail server wordt vertrouwd als het certificaat
van de certificaatautoriteit (CA) die dat certificaat heeft uitgegeven
wordt vertrouwd. Het certificaat van de CA wordt vertrouwd als ..., etc.
Dit is een Chain of Trust.

Die ketting moet ergens eindigen. Dat einde is een certificaat dat op
voorhand wordt vertrouwd: het Trust Anchor. In het algemeen zal dat een
root certificaat zijn (self signed). In het geval van pop3.dds.nl ziet
de chain of trust er als volgt uit:

0: USERTrust RSA Certification Authority (root CA)
1: Sectigo RSA Domain Validation Secure Server CA (intermediate CA)
2: signetbreedband.nl (tevens geldig voor o.a. pop3.dds.nl)

Systemen hebben een lijst van certificaten die op voorhand worden
vertrouwd: de trusted certicate cache (ook trusted root cache genaamd
omdat het in het algemeen root certificaten betreft).

In het geval van pop3.dds.nl moet dus het certificaat van 'USERTrust
RSA Certification Authority' in de trusted certificate cache zitten.

De trusted certificate cache moet door het systeem zelf (of door de
beheerder) worden onderhouden. Bij de meeste distro's gaat dat via
updates van het package 'ca-certificates'.

Post by tjoen

Post by Roger
OpenSSL verwacht de trusted root certificaten in '$(OPENSSLDIR)/certs'. De
waarde van OPENSSLDIR krijg je te zien met 'openssl version -d'.
==> Wat is de output van 'openssl version -d' ?

OPENSSLDIR: "/etc/pki/tls"

OK.

Post by tjoen

Post by Roger
==> Staan er certificaten in de certs subdirectory van OPENSSLDIR? Of is de
     certs directory leeg? (NB. 'certs' kan een link zijn naar een andere
     directory. Ook de items in 'certs' kunnen weer links zijn. Dit is bv. bij
     Debian het geval.)

Ik gebruikte
www.linuxfromscratch.org/blfs/view/stable-systemd/postlfs/make-ca.html

OK.

Post by tjoen
omdat mk-ca-bundle.pl alleen maar foutmelding geeft. Die zit ook in
curl.
$ ls /etc/pki/tls/certs/
ca-bundle.crt  dovecot.pem        objsign-ca-bundle.crt
certdata.txt   email-ca-bundle.crt
ca-bundle.crt en certdata.txt zijn van nss
De andere drie waarschijnlijk gemaakt door make-ca
De rest zit in /etc/pki/anchors/ (door make-ca)

Normaliter zou je met 'make-ca --get' je trusted (root) certificaten moeten
kunnen downloaden (certdata.txt file van Mozilla) en installeren of updaten.

Jouw OpenSSL verwacht de trusted certificaten in /etc/pki/tls/certs. Maar
als ik het 'make-ca' script goed lees, worden de certificaten voor OpenSSL
default in /etc/ssl/certs gezet.

==> Kijk eens of ze daar inderdaad staan.

Groeten,
-Roger

[tjoen]

...

Post by Roger
In het geval van pop3.dds.nl moet dus het certificaat van 'USERTrust
RSA Certification Authority' in de trusted certificate cache zitten.

Die zit in een van de files in /etc/pki/anchors/
Dat heeft make-ca van BLFS gedaan
make-ca wist ook alles in /etc/ssl/

Post by Roger
De trusted certificate cache moet door het systeem zelf (of door de
beheerder) worden onderhouden. Bij de meeste distro's gaat dat via
updates van het package 'ca-certificates'.

...

Post by Roger

Post by tjoen
OPENSSLDIR: "/etc/pki/tls"

OK.

Ik weet het niet zeker. Dovecot wil alleen /etc/ssl hebben.
Dos symlink /etc/ssl/certs naar /etc/pki/tls/certs
Ook symlink ca-certificates.crt naar ca-bundle.crt.
Aleen is filesize van ca-bundle.crt nul

Post by Roger
Normaliter zou je met 'make-ca --get' je trusted (root) certificaten moeten
kunnen downloaden (certdata.txt file van Mozilla) en installeren of updaten.

certdata.txt zit inderdaad in /etc/ssl/certs -> /etc/pki/tls/certs

Is die make-ca wel te vertrouwen?

Voorlopig werkt fetchmail dankzij die fingerprint

[Roger]

Post by tjoen

Post by Roger
In het geval van pop3.dds.nl moet dus het certificaat van 'USERTrust
RSA Certification Authority' in de trusted certificate cache zitten.

Die zit in een van de files in /etc/pki/anchors/

Mooi. Dat betekent dat de extractie van certificaten uit certdata.txt
is gelukt.

Post by tjoen
Dat heeft make-ca van BLFS gedaan
make-ca wist ook alles in /etc/ssl/

Post by Roger
De trusted certificate cache moet door het systeem zelf (of door de
beheerder) worden onderhouden. Bij de meeste distro's gaat dat via
updates van het package 'ca-certificates'.

...

Post by Roger

Post by tjoen
OPENSSLDIR: "/etc/pki/tls"

OK.

Ik weet het niet zeker. Dovecot wil alleen /etc/ssl hebben.
Dos symlink /etc/ssl/certs naar /etc/pki/tls/certs

OK.

Post by tjoen
Ook symlink ca-certificates.crt naar ca-bundle.crt.
Aleen is filesize van ca-bundle.crt nul

Post by Roger
Normaliter zou je met 'make-ca --get' je trusted (root) certificaten moeten
kunnen downloaden (certdata.txt file van Mozilla) en installeren of updaten.

certdata.txt zit inderdaad in /etc/ssl/certs -> /etc/pki/tls/certs

OpenSSL verwacht een bestand in PEM-formaat per certificaat met de naam <HASH>.0
waarbij <HASH> een hash is van het certificaat Subject. Door het gebruik van een
hash kan OpenSSL het juiste certificaat veel sneller vinden. Ter illustratie: bij
Debian ziet dat als volgt uit:

lrwxrwxrwx 1 root root 41 Apr 10 2019 fc5a8f99.0 ->
USERTrust_RSA_Certification_Authority.pem

lrwxrwxrwx 1 root root 76 Oct 6 2017 USERTrust_RSA_Certification_Authority.pem ->
/usr/share/ca-certificates/mozilla/USERTrust_RSA_Certification_Authority.crt

certdata.txt bevat de certificaatdata van de bron (Mozilla). Het formaat is niet
geschikt voor OpenSSL. Dat geldt ook voor een .crt bestand in PEM-formaat met
meerdere certificaten.

Post by tjoen
Is die make-ca wel te vertrouwen?

Als er iets mis was met make-ca, dan zouden daar wel flink wat klachten over te
vinden zijn. Ik heb heel wat slechtere shell scripts gezien.

make-ca heeft /usr/bin/trust van p11-kit nodig. Met die utility worden vanuit
de bestanden in diverse formaten (o.a. OpenSSL) gegenereerd (ik neem aan vanuit
de bestanden in /etc/pki/anchors). Dat gebeurt aan het einde van make-ca.

Ik vermoed dat p11-kit niet of niet goed geïnstalleerd is geweest toen je
make-ca draaide. Controleer eens goed of p11-kit in orde is. Kijk eens of
je het certificaat van USERTrust_RSA_Certification_Authority ziet in de
output van 'trust list'.

Als p11-kit in orde lijkt te zijn, kun je 'make-ca --get --force' doen om een
nieuwe data download en rebuild van de certificate cache te forceren.

Als de certificaatbestanden voor OpenSSL correct zijn gegenereerd moeten er
in /etc/ssl/certs ruim 100 entries zijn van het type '<HASH>.0'.

Groeten,
-Roger

[tjoen]

Post by Roger

Post by tjoen

Post by Roger
In het geval van pop3.dds.nl moet dus het certificaat van 'USERTrust
RSA Certification Authority' in de trusted certificate cache zitten.

Die zit in een van de files in /etc/pki/anchors/

Mooi. Dat betekent dat de extractie van certificaten uit certdata.txt
is gelukt.

Alleen ik snap niet hoe openssl weet dat die directory bestaat.
grep in de source van openssl geen combonatie pki en etc
Idem anchor en etc

Post by Roger

Post by tjoen
Ik weet het niet zeker. Dovecot wil alleen /etc/ssl hebben.
Dos symlink /etc/ssl/certs naar /etc/pki/tls/certs

OK.

LFS heeft --openssldir /etc/ssl. Ik overweeg openssl opnieuw
te bouwen met de LFS directory

Post by Roger
OpenSSL verwacht een bestand in PEM-formaat per certificaat met de naam <HASH>.0

Hier fc5a8f99.p11-kit

Post by Roger
lrwxrwxrwx 1 root root     41 Apr 10  2019 fc5a8f99.0 ->
USERTrust_RSA_Certification_Authority.pem

Die file heb ik nooit gezien, vermoedelijk gedownload door make-ca.
en later renamed fc5a8f99.p11-kit

Post by Roger
lrwxrwxrwx 1 root root     76 Oct  6  2017
USERTrust_RSA_Certification_Authority.pem ->
/usr/share/ca-certificates/mozilla/USERTrust_RSA_Certification_Authority.crt

in cert/ alleen
-r--r--r-- 1 root root 0 Mar 11 11:45 ca-bundle.crt
lrwxrwxrwx 1 root root 13 Mar 15 18:57 ca-certificates.crt -> ca-bundle.crt
-r--r--r-- 1 root root 0 Mar 11 11:45 email-ca-bundle.crt
-r--r--r-- 1 root root 0 Mar 11 11:45 objsign-ca-bundle.crt

..

Post by Roger
Ik vermoed dat p11-kit niet of niet goed geïnstalleerd is geweest toen je
make-ca draaide. Controleer eens goed of p11-kit in orde is. Kijk eens of
je het certificaat van USERTrust_RSA_Certification_Authority ziet in de
output van 'trust list'.

..

Post by Roger
Als de certificaatbestanden voor OpenSSL correct zijn gegenereerd moeten er
in /etc/ssl/certs ruim 100 entries zijn van het type '<HASH>.0'.

Voor de zekerheid zal ik eerst openssl herbouwen
/etc/ssl en /etc/pki schoonmaken en
openssl, nss en p11-kit herinstalleren

[tjoen]

...

Post by tjoen

Post by Roger
Ik vermoed dat p11-kit niet of niet goed geïnstalleerd is geweest toen je
make-ca draaide. Controleer eens goed of p11-kit in orde is. Kijk eens of
je het certificaat van USERTrust_RSA_Certification_Authority ziet in de
output van 'trust list'.

..

...

Post by tjoen
Voor de zekerheid zal ik eerst openssl herbouwen
/etc/ssl en /etc/pki schoonmaken en
openssl, nss en p11-kit herinstalleren

Mijn openssl, p11-kit en nss verkeerd gebouwd
Openssl moet toch in /etc/ssl
p11-kit en nss zijn bij BLFS zwaar gepatched.
Indien ik ze zo zou bouwen verwacht ik dat /etc/pki niet meer nodig zijn
en make-ca zich normaal gedraagt

[Roger]

Post by tjoen
...

Post by tjoen

Post by Roger
Ik vermoed dat p11-kit niet of niet goed geïnstalleerd is geweest toen je
make-ca draaide. Controleer eens goed of p11-kit in orde is. Kijk eens of
je het certificaat van USERTrust_RSA_Certification_Authority ziet in de
output van 'trust list'.

..

...

Post by tjoen
Voor de zekerheid zal ik eerst openssl herbouwen
/etc/ssl en /etc/pki schoonmaken en
openssl, nss en p11-kit herinstalleren

Mijn openssl, p11-kit en nss verkeerd gebouwd
Openssl moet toch in /etc/ssl
p11-kit en nss zijn bij BLFS zwaar gepatched.
Indien ik ze zo zou bouwen verwacht ik dat /etc/pki niet meer nodig zijn
en make-ca zich normaal gedraagt

Softwarecomponenten zijn in elke distro aangepast zodat ze correct samenwerken.
Het verstandigste is om ze te bouwen met de defaults van BLFS. Als je daaraan
gaat sleutelen, moet je verdomd goed weten wat je aan het doen bent. Anders
vraag je om problemen.

Groeten,
-Roger

[tjoen]

On 3/17/24 07:11, Roger wrote:
..

Post by Roger
Softwarecomponenten zijn in elke distro aangepast zodat ze correct samenwerken.
Het verstandigste is om ze te bouwen met de defaults van BLFS. Als je daaraan
gaat sleutelen, moet je verdomd goed weten wat je aan het doen bent. Anders
vraag je om problemen.

Ik heb inderdaad openssl, nss en p11-kit herbouwd vlgs (B)LFS.
fetchmail werkt nu ook zonder fingerprint
make-ca heeft nu inderdaad zijn werk gedaan: /etc/ssl/ en /etc/pki/
volgepropt met files en symlinks
Eigenaardig is dat /etc/ssl/certs/ca-certificates.crt is verdwenen.
Wel nieuwe /etc/pki/tls/certs/ca-bundle.crt aangemaakt

Nog bedankt voor alle hulp

[tjoen]

On 3/12/24 20:49, Roger wrote:
..

  "Almost all options have a corresponding keyword which can be used
   to declare them in a .fetchmailrc file."

alleen sslcertck (meerdere pogingen) geeft syntax error. Voor de rest
werkt het:

poll pop3.dds.nl with protocol pop3
user tjoen there is ***@compute1 here
ssl sslfingerprint "etc

passwd zit in .netrc

[Roger]

Post by tjoen
alleen sslcertck (meerdere pogingen) geeft syntax error. Voor de rest

Vreemd. Wat exact heb je geprobeerd in je .fetchmailrc te zetten?

Groeten,
-Roger

[tjoen]

Post by Roger

Post by tjoen
alleen sslcertck (meerdere pogingen) geeft syntax error. Voor de rest

Vreemd. Wat exact heb je geprobeerd in je .fetchmailrc te zetten?

.fetchmairc:
poll pop3.dds.nl with protocol pop3
user tjoen there is ***@compute1 here
ssl sslfingerprint "etc

Geprobeerd sslcertck nosslcertck sslcertck=0 ook in andere regels.
--sslcertck ook syntaxerror

[Roger]

Post by tjoen

Post by Roger

Post by tjoen
alleen sslcertck (meerdere pogingen) geeft syntax error. Voor de rest

Vreemd. Wat exact heb je geprobeerd in je .fetchmailrc te zetten?

poll pop3.dds.nl with protocol pop3
ssl sslfingerprint "etc
Geprobeerd sslcertck nosslcertck sslcertck=0 ook in andere regels.
--sslcertck ook syntaxerror

Met trial and error los je geen problemen op. Lees de documentatie van
'--nosslcertck' eens zorgvuldig.

Groeten,
-Roger

[tjoen]

...

Post by Roger

Post by tjoen
Geprobeerd sslcertck nosslcertck sslcertck=0 ook in andere regels.
--sslcertck ook syntaxerror

Met trial and error los je geen problemen op. Lees de documentatie van
'--nosslcertck' eens zorgvuldig.

Het werkt momenteel met shellscript
/usr/bin/fetchmail --nosslcertck
De rest staat in ~/.rcfetchmail

Als ik tijd heb ga ik de source van fetchmail lezen

[Adri Verhoef]

Op moederschip aarde schreef iemand die zich identificeerde als

Post by Roger

Post by tjoen
...

Post by Roger
fetchmail -v --nosslcertck --sslfingerprint 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Vlgs de FAQ voorbeeld moet die 00:00.. tussen quotes ""

De manual zegt er niets over, maar het is inderdaad een string.

Zijn er shells die "00:00:00:00" anders interpreteren dan 00:00:00:00 (ongequoot)?
Als het niet nodig is, kan je ze net zo goed weglaten, lijkt mij.

[tjoen]

On 3/12/24 10:42, Roger wrote:
...

Post by Roger

Post by tjoen
$ fetchmail
fetchmail: Server certificate verification error: self-signed
  certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
  Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
  Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
  in the trusted CA certificate location, or that c_rehash needs to be
  run on the certificate directory. For details, please see the
  documentation of --sslcertpath and --sslcertfile in the manual page.
  See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
  verify failed
fetchmail: pop3.dds.nl: upgrade to TLS failed.
fetchmail: Query status=2 (SOCKET)

De documentatie zeg bij -v niets over de fingerprint. Je zou -v -v
kunnen proberen voor meer detail.

Geen fingerprint

Post by Roger
  To obtain the fingerprint of a certificate stored in the file
    openssl x509 -in cert.pem -noout -md5 -fingerprint

Ik heb deze niet. Mogelijk door distro aangemaakt met echte cert

[Roger]

Post by tjoen
...

Post by Roger

Post by tjoen
$ fetchmail
fetchmail: Server certificate verification error: self-signed
  certificate in certificate chain
fetchmail: Missing trust anchor certificate: /C=US/ST=New
  Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
  Certification Authority
fetchmail: This could mean that the root CA's signing certificate is not
  in the trusted CA certificate location, or that c_rehash needs to be
  run on the certificate directory. For details, please see the
  documentation of --sslcertpath and --sslcertfile in the manual page.
  See README.SSL for details.
fetchmail: OpenSSL reported: error:0A000086:SSL routines::certificate
  verify failed
fetchmail: pop3.dds.nl: upgrade to TLS failed.
fetchmail: Query status=2 (SOCKET)

De documentatie zeg bij -v niets over de fingerprint. Je zou -v -v
kunnen proberen voor meer detail.

Geen fingerprint

Post by Roger
   To obtain the fingerprint of a certificate stored in the file
     openssl x509 -in cert.pem -noout -md5 -fingerprint

Ik heb deze niet. Mogelijk door distro aangemaakt met echte cert

Wat is 'deze'? Als je 'cert.pem' bedoelt: daarvoor moet je het bestand
met het certificaat van pop3.dds.nl substitueren.

Groeten,
-Roger

[tjoen]

...

Post by Roger

Post by tjoen

Post by Roger
     openssl x509 -in cert.pem -noout -md5 -fingerprint

Ik heb deze niet. Mogelijk door distro aangemaakt met echte cert

Wat is 'deze'? Als je 'cert.pem' bedoelt: daarvoor moet je het bestand
met het certificaat van pop3.dds.nl substitueren.

Die zou op de server staan? Maar die gaf toch:

fetchmail: Missing trust anchor certificate: /C=US/ST=New
Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA
Certification Authority