DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Security

OpenBSD Security Functionally paranoid!

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 21st September 2016
shep shep is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,070
Default [SOLVED]tls certificate for alpine email client

On 6.0amd64 release, my new email server uses a tls certificate but I'm having difficulty setting it up properly.

Apparently mail/alpine is not using the system wide certificates in /etc/ssl/cert.pem. I get the following message when I start alpine
Code:
unable to get local issuer certificate (details)
The details
Code:
Host given by user:

  mail.centurylink.net

Reason for failure:

  unable to get local issuer certificate

Certificate being verified:

  /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
There is an option to bypass the certificate with
Code:
 mail.centurylink.net/novalidate-cert
which I view as short cut.

Ideally, I would either like to have alpine use the system wide certifcates or use locally use the certificates I fetched for my mutt configuration ~/.config/mutt/certificates/certs
Code:
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGbMIIBlzAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwbQYI
KwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQU
j+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29t
L3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPgYDVR0lBDcwNQYIKwYBBQUHAwEGCCsGAQUFBwMC
BggrBgEFBQcDAwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEBBQUA
A4GBABMC3fjohgDyWvj4IAxZiGIHzs73Tvm7WaGY5eE43U68ZhjTresY8g3JbT5K
lCDDPLq9ZVTGr0SzEK0saz6r1we2uIFjxfleLuUqZ87NMwwq14lWAyMfs77oOghZ
tOxFNfeKW/9mz1Cvxm1XjRl4t7mi0VfqH5pLr7rJjhJ+xr3/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQUT+5dDhwtzRAQY0wkwaZ/zANBgkqhkiG9w0BAQsFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTMxMDMxMDAwMDAwWhcNMjMxMDMwMjM1OTU5WjB+MQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV
BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVjIENs
YXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAstgFyhx0LbUXVjnFSlIJluhL2AzxaJ+aQihiw6UwU35VEYJb
A3oNL+F5BMm0lncZgQGUWfm893qZJ4Itt4PdWid/sgN6nFMl6UgfRk/InSn4vnlW
9vf92Tpo2otLgjNBEsPIPMzWlnqEIRoiBAMnF4scaGGTDw5RgDMdtLXO637QYqzu
s3sBdO9pNevK1T2p7peYyo2qRA4lmUoVlqTObQJUHypqJuIGOmNIrLRM0XWTUP8T
L9ba4cYY9Z/JJV3zADreJk20KQnNDz0jbxZKgRb78oMQw7jW2FUyPfG9D72MUpVK
Fpd6UiFjdS8W+cRmvvW1Cdj/JwDNRHxvSz+w9wIDAQABo4IBYzCCAV8wEgYDVR0T
AQH/BAgwBgEB/wIBADAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vczEuc3ltY2Iu
Y29tL3BjYTMtZzUuY3JsMA4GA1UdDwEB/wQEAwIBBjAvBggrBgEFBQcBAQQjMCEw
HwYIKwYBBQUHMAGGE2h0dHA6Ly9zMi5zeW1jYi5jb20wawYDVR0gBGQwYjBgBgpg
hkgBhvhFAQc2MFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v
Y3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMCkG
A1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTUzNDAdBgNVHQ4E
FgQUX2DPYZBV34RDFIpgKrL1evRDGO8wHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnz
Qzn6Aq8zMTMwDQYJKoZIhvcNAQELBQADggEBAF6UVkndji1l9cE2UbYD49qecxny
H1mrWH5sJgUs+oHXXCMXIiw3k/eG7IXmsKP9H+IyqEVv4dn7ua/ScKAyQmW/hP4W
Ko8/xabWo5N9Q+l0IZE1KPRj6S7t9/Vcf0uatSDpCr3gRRAMFJSaXaXjS5HoJJtG
QGX0InLNmfiIEfXzf+YzguaoxX7+0AjiJVgIcWjmzaLmFN5OUiQt/eV5E1PnXi8t
TRttQBVSK/eHiXgSgW7ZTaoteNTCLD0IX4eRnh8OsN4wUmSGiaqdZpwOdgyA8nTY
Kvi4Os7X1g8RvmurFPW9QaAiY4nxug9vKWNmLT+sjHLF+8fk1A/yO0+MKcc=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIGcjCCBVqgAwIBAgIQTsPFd6DHuVkx1SigBAVP3zANBgkqhkiG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE2MDMwMjAwMDAwMFoX
DTE3MDMxMjIzNTk1OVowgYwxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlMb3Vpc2lh
bmExDzANBgNVBAcMBk1vbnJvZTEUMBIGA1UECgwLQ2VudHVyeUxpbmsxIzAhBgNV
BAsMGkludGVyYWN0aXZlIFNlcnZpY2VzIEdyb3VwMR0wGwYDVQQDDBRtYWlsLmNl
bnR1cnlsaW5rLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALDn
1a+5+Z5hwI2CTV8oVJ7mygbvz8aIO+OfJdw7bCEir9oNn4qOoshcnNJFJWgNqxTG
TIHhKf2PJwfeaodHzhGsfPpm2lCfYKGqBnjEDKegIQmleBxSImk3hRWaWKxr6A7s
m7G26kkVqOSyzTRviULQ22WdzwG4Kz30zq3+uMByDo4mlY9usXqlxm7E0T3OWuVq
mTqwG3b1dT8Sv/0n+33t13s/Rs44QIdJkKh8SE+SHwVEglnqFtrQI1v8j1+RZpsr
Hx9v5CbaZf5tdQFkz5Idjybh+FB1UqwKv8yJ62ZSJqXEcjizUnRL7uIc8TwtX/S+
crfG8SCVG8327V+aaCkCAwEAAaOCAtswggLXMIGIBgNVHREEgYAwfoIUbWFpbC5j
ZW50dXJ5bGluay5uZXSCE3BvcC5jZW50dXJ5bGluay5uZXSCFHNtdHAuY2VudHVy
eWxpbmsubmV0ghJteC5jZW50dXJ5bGluay5uZXSCE3NtdHAuZW1iYXJxbWFpbC5j
b22CEnBvcC5lbWJhcnFtYWlsLmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwYQYDVR0gBFowWDBWBgZn
gQwBAgIwTDAjBggrBgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9jcHMwJQYI
KwYBBQUHAgIwGRoXaHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwHwYDVR0jBBgwFoAU
X2DPYZBV34RDFIpgKrL1evRDGO8wKwYDVR0fBCQwIjAgoB6gHIYaaHR0cDovL3Nz
LnN5bWNiLmNvbS9zcy5jcmwwVwYIKwYBBQUHAQEESzBJMB8GCCsGAQUFBzABhhNo
dHRwOi8vc3Muc3ltY2QuY29tMCYGCCsGAQUFBzAChhpodHRwOi8vc3Muc3ltY2Iu
Y29tL3NzLmNydDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AN3rHSt6DU+mIIuB
rYFocH4ujp0B1VyIjT0RxM227L7MAAABUzfW+icAAAQDAEcwRQIhAPa/j9+tsIna
i22blK1c/sjCKkAl4IrT4CJ/+oKbggJhAiBUrDjaHEVaG0tHpn91A42px1+3fEO9
FXGsUd5YjoaCTAB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAAB
UzfW+jsAAAQDAEcwRQIgdWd55+T3MqWVSKii36HheZexjrRh1OD+wOXK+nrAlbIC
IQCUJT0A6CyQrLeEgH+UeLVb/GOsmTngkel7pO8Hbv2OjjANBgkqhkiG9w0BAQsF
AAOCAQEAhGL229tDTroUjABwkBsAMZTfFbkZaRL1dQJ6PQUmvI/ab0Jefm+W0kpo
tSe8oaQ/46o650pNzvXaziPh0XIOSBAKN8nlZwxMAfSoBYCHTGzS9ZGRcwCuY8s7
Ejo2I7hQFjyvqubhl45rEnBkg7y1t6w3sEFAQB93lrvujsuH5SkPYk3DqY616JOP
6dHMEPvP2L02ML/jL0Wc1Nv84ZYCXQnyLFzIrhgE4/WA5gGoFE6SjQus5wZbl2G/
j6CUnPiNacOamdsphVt5Ch6bvz0pEd5EMjyUHG5A9Q7wXfy4UebhWljNDu5XoSU1
EPUJynzepCe/P48Eyl/xYPD1ZmTrCQ==
-----END CERTIFICATE-----
I grep'd one of the lines in the above certificate against /etc/ssl/cert.pem and did not get a match. I'm guessing it is missing.

Alpine has the following certificate options
Code:
# Public certificates are kept in files in this directory. The files should
# contain certificates in PEM format. The name of each file should look
# like <emailaddress>.crt. The default directory is .alpine-smime/public.
smime-public-cert-directory=

# If this option is set then public certificates are kept in a single container
# "file" similar to a remote configuration file instead of in the
# smime-publiccert-directory. The value can be a remote or local folder
# specification like for a non-standard pinerc value. The default
# is that it is not set.
smime-public-cert-container=/etc/ssl/cert.pem

# Private keys are kept in files in this directory. The files are in PEM format.
# The name of a file should look like <emailaddress>.key.
# The default directory is .alpine-smime/private.
smime-private-key-directory=

# If this option is set then private keys are kept in a single container
# "file" similar to a remote configuration file instead of in the
# private-key-directory. The value can be a remote or local folder
# specification like for a non-standard pinerc value. The default
# is that it is not set.
smime-private-key-container=

# Certificate Authority certificates (in addition to the normal CACerts for the
# system) are kept in files in this directory. The files are in PEM format.
# Filenames should end with .crt. The default directory is .alpine-smime/ca.
smime-cacert-directory=

# If this option is set then CAcerts are kept in a single container
# "file" similar to a remote configuration file instead of in the
# ca-cert-directory. The value can be a remote or local folder
# specification like for a non-standard pinerc value. The default
# is that it is not set.
smime-cacert-container=
I wonder why the centurylink certificates were not included and am leaning towards using the certificates in a ~/ file. Any suggestions on setting a local public file for alpine?

Edit:
I found this widely referenced pine-ssl link and tried setting up a /etc/ssl/certs/ directory and making a ~/.alpine-smime/ca/centurylink_tls.crt but still get the local certificate failure.

Last edited by shep; 27th September 2016 at 02:13 PM. Reason: added madboa howto link
Reply With Quote
  #2   (View Single Post)  
Old 22nd September 2016
shep shep is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,070
Default

I narrowed it down to a lack of certificates in /etc/ssl/cert.pem.

I tried to append the mail.centurylink.net certificate to the /etc/ssl/cert.pem without success but remembered a Gentoo wiki where individual certificates were concatenated into a single cert.pem file.
Quote:
CA Certificate Files
This approach uses CA certificate files, which are stored in the /etc/ssl/certs/ directory. As WebKit only supports a single PEM file, one can simply concatenate all separate files into a single one with the following command:

user $cd /etc/ssl/certs/ && for i in `ls`; do cat $i >> ~/.xombrero/cert.pem; done
.

I generated the cert.pem file on a Debian 8 system, renamed the /etc/ssl/cert.pem and copied the Debian certificate file from a usb thumb drive.

My alpine email client now works with centurylink tls/ssl but I feel like it was overkill. The Debian based cert.pem is 5x larger
Code:
Heffalump# ls -al
total 2580
drwxr-xr-x   4 root  wheel      512 Sep 21 18:55 .
drwxr-xr-x  39 root  wheel     2048 Sep 21 13:14 ..
-r--r--r--   1 root  bin    1097360 Sep 21 18:54 cert.pem
-r--r--r--   1 root  bin     189049 Sep 21 16:27 cert_bu
-rw-r--r--   1 root  wheel     2669 Jul 26 11:47 ikeca.cnf
drwxr-xr-x   2 root  wheel      512 Jul 26 11:47 lib
-r--r--r--   1 root  bin        745 Jul 26 11:47 openssl.cnf
drwx------   2 root  wheel      512 Jul 26 11:47 private
-r--r--r--   1 root  bin       1006 Jul 26 11:47 x509v3.cnf
It would have been nice to just add the certificates for my email provider.
Reply With Quote
  #3   (View Single Post)  
Old 26th September 2016
fvgit's Avatar
fvgit fvgit is offline
Fdisk Soldier
 
Join Date: May 2016
Location: perl -MMIME::Base64 -le 'print decode_base64("SGVyZSBiZSBkcmFnb25zC")'
Posts: 72
Default

Quote:
Originally Posted by shep View Post
I narrowed it down to a lack of certificates in /etc/ssl/cert.pem.

(...)

It would have been nice to just add the certificates for my email provider.
I'm just testing my setup, but like you, my email provider's certificate wasn't included in /etc/ssl/cert.pem.

I added it as a separate file:
Code:
/etc/ssl/myprovider.pem
and then did the obligatory:
Code:
openssl certhash /etc/ssl/
Worked for me.
Reply With Quote
  #4   (View Single Post)  
Old 26th September 2016
shep shep is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,070
Default

Thanks.

I am still doing something wrong. Alpine email works fine in Debian and with with a cert.pem that I generate from Debian /etc/ssl/certs. The generated file just contains
Code:
-----BEGIN CERTIFICATE-----
MII......
-----END CERTIFICATE-----
No fingerprints or descriptions about the certificate itself.

Using $ openssl s_client -showcerts -connect mail.centurylink.net:993 </dev/null


I retrieve 3 certificates. The first, which I read to be the missing server certificate is Signed by Symantec. A quick "grep" of OpenBSD cert.pem does not match Symantec. The second 2 certificates are from Verisign 2006

I copied the 1st certificate content, into an /etc/ssl/centurylink.pem, change the centurylink.pem group wheel => bin and run # openssl certhash /etc/ssl.

Alpine still complains
Reply With Quote
  #5   (View Single Post)  
Old 26th September 2016
fvgit's Avatar
fvgit fvgit is offline
Fdisk Soldier
 
Join Date: May 2016
Location: perl -MMIME::Base64 -le 'print decode_base64("SGVyZSBiZSBkcmFnb25zC")'
Posts: 72
Default

Quote:
Originally Posted by shep View Post
I retrieve 3 certificates. The first, which I read to be the missing server certificate is Signed by Symantec. A quick "grep" of OpenBSD cert.pem does not match Symantec. The second 2 certificates are from Verisign 2006
I just checked, and unless I'm reading things wrongly, the 1st certificate, the one for Centurylink has Symantec as its Certificate Authority:
Code:
Certificate chain
 0 s:/C=US/ST=Louisiana/L=Monroe/O=CenturyLink/OU=Interactive Services Group/CN=mail.centurylink.net
   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
-----BEGIN CERTIFICATE-----
MIIGcjCCBVqgAwIBAgIQTsPFd6DHuVkx1SigBAVP3zANBgkqhkiG9w0BAQsFADB+
(...)
, the 2nd certificate for Symantec has Verisign as its Certificate Authority
Code:
 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQUT+5dDhwtzRAQY0wkwaZ/zANBgkqhkiG9w0BAQsFADCB
(...)
and the 3rd one is from Verisign themselves:
Code:
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
(...)
Quote:
Originally Posted by shep View Post
I copied the 1st certificate content, into an /etc/ssl/centurylink.pem, change the centurylink.pem group wheel => bin and run # openssl certhash /etc/ssl.

Alpine still complains
You'd have to add all three certificates, not just the centurylink one, if I'm not mistaken. But somehow the certificate chain seems to be broken. I just added all three certificates to my machine and it didn't work.

BTW, before introducing alpine into the mix you can check the certificates directly:

Code:
openssl s_client -connect mail.centurylink.net995 -CApath /etc/ssl/
Assuming /etc/ssl/ is where you placed all your certificates. I can connect to their pop3 server but get a
Code:
Verify return code: 20 (unable to get local issuer certificate)
Normally you'd see a
Code:
Verify return code: 0 (ok)
before the POP3 prompt.

I'm stumped, right now. The whole ssl certificate thing is relatively new to me. But, if it works on Debian for you, it has to be solvable. You might check your Debian-generated cert.pem for the Verisign certificates and compare those to the OpenBSD one. Other than that I don't know...

Last edited by fvgit; 26th September 2016 at 09:41 PM. Reason: Better wording & a typo
Reply With Quote
  #6   (View Single Post)  
Old 26th September 2016
shep shep is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,070
Default

Using CApath to /etc/ssl, I get the same error code
Code:
Verify return code: 20 (unable to get local issuer certificate)
My understanding is that the 1st is the server certificate, the 2nd is an intermediate certificate and the 3rd is the CA certificate.

I have been using mutt w/ fetchmail on centurylink's pop3 server but choose alpine/imap for my laptop as I did not want all my emails archived on a device that is easy to carry off.

I'm also leaning ssl certificates and actually have been able to generate a cert.pem from my Debian Dual Boot. Debian uses a different certificate format where all certificates are individual files under /etc/ssl/cert. As I mentioned in my original post, I found a script that concatonates all the separate Debian files into a single cert.pem and although 5x larger than the original cert.pem does work.

With fetchmail, I can get generate a fingerprint on the downloaded certificate and retrieve pop3 emails now via tls. I'm debating implementing fetchmail on the laptop with mutt or alpine, but I definitely want imap on the laptop.

Last edited by shep; 27th September 2016 at 02:16 PM.
Reply With Quote
  #7   (View Single Post)  
Old 27th September 2016
fvgit's Avatar
fvgit fvgit is offline
Fdisk Soldier
 
Join Date: May 2016
Location: perl -MMIME::Base64 -le 'print decode_base64("SGVyZSBiZSBkcmFnb25zC")'
Posts: 72
Default

Quote:
Originally Posted by shep View Post
Using CApath to /etc/ssl, I get the same error code
Code:
Verify return code: 20 (unable to get local issuer certificate)
My understanding is that the 1st is the server certificate, the 2nd is an intermediate certificate and the 3rd is the CA certificate.
I'm thinking the problem lies with the 3rd certificate, that ssl can't validate it.

Quote:
Originally Posted by shep View Post
Debian uses a different certificate format where all certificates are individual files under /etc/ssl/cert. As I mentioned in my original post, I found a script that concatonates all the separate Debian files into a single cert.pem and although 3x larger than the original cert.pem does work.
What format are the Debian certificates exactly in?

Quote:
Originally Posted by shep View Post
With fetchmail, I can get generate a fingerprint on the downloaded certificate and retrieve pop3 emails now via tls.
You can also generate the fingerprint with ssl:
Code:
openssl x509 -in centurylink.pem -noout -md5 -fingerprint > output.file.with.fingerprint
Reply With Quote
  #8   (View Single Post)  
Old 27th September 2016
shep shep is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,070
Default

Quote:
What format are the Debian certificates exactly in?
From Certificate Stores and Platforms

Quote:
For OpenSSL (and derivatives like LibreSSL), a store of trusted CA certificates can be a single file containing one or more concatenated certificates in PEM format, or a directory containing individual certificate files in PEM format, where each file is named in a specific format according to its hash value (these directories are usually produced by running the c_rehash command on a directory full of certificate files with more human-readable names, which produces symlinks in the expected format; p11-kit‘s trust extract / p11-kit extract command also has some support for doing this).
*****clip
In Debian, the system ultimately populates the /etc/ssl/certs directory with certificate files and runs c_rehash on it. It also produces a bundle file, /etc/ssl/certs/ca-certificates.crt. I’m not sure which is considered ‘preferred’ for Debian purposes, if either is – but on Debian and derivatives, you can rely on /etc/ssl/certs being usable as a hashed directory, and /etc/ssl/certs/ca-certificates.crt as a bundle file.
Reply With Quote
  #9   (View Single Post)  
Old 27th September 2016
TronDD TronDD is offline
Package Pilot
 
Join Date: Sep 2014
Posts: 155
Default

This appears to be the missing root:
https://www.tbs-certificates.co.uk/FAQ/en/30.html

The chain you get from 's_client -showcerts' does not include it.

Copy it from the site and append it to the end of cert.pem with cat (or paste in with a text editor) and it should work.

$ openssl s_client -connect mail.centurylink.net:995
...
Verify return code: 0 (ok)
---
+OK POP3 ready
Reply With Quote
Old 27th September 2016
shep shep is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,070
Default

@TronDD

Thank you, I would have never found this
The appended crt works with mutt/fetchmail/pop3 and alpine/imap. The solution is 5x cleaner.

In my searches I found that several certs were added in the 5.9 changelog. I'm thinking this should be added since the certificate was renewed. Can I submit crediting you?

Last edited by shep; 27th September 2016 at 02:16 PM.
Reply With Quote
Old 27th September 2016
TronDD TronDD is offline
Package Pilot
 
Join Date: Sep 2014
Posts: 155
Default

It was removed on purpose for 5.8. Not sure why. Maybe the expiration, or maybe because it's a weak cert (1024). Everyone is deprecating SHA1 by the end of the year.

http://cvsweb.openbsd.org/cgi-bin/cv...-cvsweb-markup

You should ask Centurymail to update to a new cert.

Also, how I found this, you were looking at it but didn't know:
Quote:
and the 3rd one is from Verisign themselves:

2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
The 's' is the subject of the cert you are looking at, given to you by -showcerts. The 'i' is "issued by". Meaning there is another cert in the chain, keep going. Then I just googled that subject to find the cert.
Reply With Quote
Old 27th September 2016
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 5,980
Default

(This should be read out loud, in the voice of George Takei..)

"Oh, my..."

That particular link reference by TronDD was to remove a cert from 5.8-stable, and it was committed at my request. Is this the same cert? Serial numbers are different.

The reason for my request? r1.8 to cert.pem, committed to -current the same day. The commit states:
Quote:
Remove "C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification
Authority" (serial 3c:91:31:cb:1f:f6:d0:1b:0e:9a:b8:d0:44:bf:12:be) root
certificate from cert.pem. ok rpe@

Symantec/VeriSign say "Browsers/root store operators are encouraged to
remove/untrust this root from their root stores" and "hasn't been used to
generate new certificates in several years, and will now be repurposed to
provide transition support for some of our enterprise customers' legacy,
non-public applications"
If this is the same cert, then this is best taken to CenturyLink's certificate management group to repair.

FYI: This is an example of a patch to -stable that did not meet the requirement to be published as errata.
Reply With Quote
Old 27th September 2016
TronDD TronDD is offline
Package Pilot
 
Join Date: Sep 2014
Posts: 155
Default

Hmm.. Yes, they are different. The end date is a day off. One used SHA1 for the signature, the other is md2.

I don't know how many of these certs with the same subject they had...
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
alpine with .pine-passfile support slowtechstef OpenBSD Packages and Ports 3 26th February 2016 10:30 PM
Alpine Linux J65nko Other BSD and UNIX/UNIX-like 5 3rd July 2015 01:12 PM
Alpine (.pinerc) configuration help cssgalactic FreeBSD General 1 1st March 2011 05:26 AM
OBSD client hangs mounting NFS; Linux client doesn't amorphousone OpenBSD General 7 26th August 2010 05:21 AM
Alpine not working tomageeni OpenBSD General 7 2nd April 2010 10:06 PM


All times are GMT. The time now is 02:57 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick