Just trying to set up a simple SSL server. I have never had anything SSL work for me in the past. I have a loose understanding of how SSL certificates and signing.
The code is simple
import socket, ssl
context = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
context.load_cert_chain(certfile="mycertfile") ###############
bindsocket = socket.socket()
bindsocket.bind(('', 2099))
bindsocket.listen(5)
while True:
newsocket, fromaddr = bindsocket.accept()
sslsoc = context.wrap_socket(newsocket, server_side=True)
request = sslsoc.read()
print(request)
The line in there with the ###s after it is the one that isnt working. I don't know what I have to do with openssl to generate a PEM file that will work here.
Can anyone enlighten me as to how to make this simple socket work.
By the way, this is NOT used for HTTP.
you can use this command to generate a self-signed certificate
openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem
the openssl framework will ask you to enter some information, such as your country, city, etc. just follow the instruction, and you will get a cert.pem file. the output file will have both your RSA private key, with which you can generate your public key, and the certificate.
the output file looks like this:
-----BEGIN RSA PRIVATE KEY-----
# your private key
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
# your certificate
-----END CERTIFICATE-----
just load it, and the ssl module will handle the rest for you:
context.load_cert_chain(certfile="cert.pem", keyfile="cert.pem")
btw, there is no "SSLContext" in python2. for guys who are using python2, just assign the pem file when wrapping socket:
newsocket, fromaddr = bindsocket.accept()
connstream = ssl.wrap_socket(newsocket,
server_side=True,
certfile="cert.pem",
keyfile="cert.pem",
ssl_version=YOUR CHOICE)
available ssl version: ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv23. if you have no idea, ssl.PROTOCOL_SSLv23 may be your choice as it provides the most compatibility with other versions.
In your example, you provide a certfile, but no keyfile. Both are required.
Related
A python deployment our team has fails on
import socket
import ssl
context = ssl.wrap_socket(
sock,
ca_certs='root_ca_bundle.pem',
keyfile='pk.pem',
certfile='cert.pem',
do_handshake_on_connect=True,
cert_reqs=ssl.CERT_REQUIRED,
)
which is traced to failing on load_cert chain function with
if certfile:
context.load_cert_chain(certfile, keyfile)
The error I see is this
[X509: KEY_VALUES_MISMATCH] key values mismatch (_ssl.c:4067)
The real issue is that I copied a wrap_socket call using the same certfile,keyfile and ca_certs, and I don't see this issue.
It only appears on deployment.
To my understanding, load_cert_chain just verifies that the certfile and keyfile are mathematically aligned, using something like this:
$ openssl x509 -noout -modulus -in cert.pem
$ openssl rsa -noout -modulus -in key-no-pass.pem
Tried this on key and cert and verified they're the same.
What I am asking is :
Is there an explanation other than wrong keyfile or certfile being used in deployment?
Is there a way I can find source code for load_cert_chain function.
I generated the certificate and the private key with openssl for the client and for the server, the code of both of them is in python and they have a communication gRPC for federated learning process. I tried to get the gRPC connection a secure connection but i got problems, gRPC secure connection is based on ssl security for this reason i generated certificate and private key for client and server with openssl.
Checking the certificates(client and server are similar) openssl gave me this:
openssl x509 -in /home/torino/Desktop/certificate.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
6f:12:4e:5c:8d:a4:d0:f3:ef:4e:14:73:bb:cc:b3:bf:0c:9b:e9:84
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = IT, ST = Itali, O = Uni, CN = *
Validity
Not Before: Nov 8 16:01:13 2021 GMT
Not After : Nov 8 16:01:13 2022 GMT
Subject: C = IT, ST = Itali, O = Uni, CN = *
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:db:17:4a:18:29:cd:12:c8:77:89:4b:9e:21:f1:
d4:ca:0a:6d:7c:71:f9:a8:3c:31:11:d2:4b:48:5d:
ab:be:fa:9b:44:c0:e9:fb:26:c1:32:7f:a6:09:38:
73:e9:18:73:56:7a:5e:31:4c:74:2b:c6:66:fa:5f:
c2:ab:4a:84:72:86:16:fc:fd:a4:5e:1b:74:f5:b4:
57:33:d4:ae:0a:83:82:bb:66:29:ce:00:f8:5e:fc:
28:93:78:c2:f3:0c:3e:69:3f:4a:27:25:47:3a:6c:
01:63:07:58:a5:f4:8f:11:3e:29:cf:fc:19:ab:30:
9b:97:d7:d2:6f:a2:89:12:14:65:74:8b:bd:ef:dd:
c0:3b:30:6c:2d:be:48:1a:c0:46:41:ab:fa:a8:39:
b8:cb:bb:e0:63:89:e3:a6:4f:a3:4c:8e:52:5c:45:
ed:79:80:a7:8e:bd:cc:26:bb:cb:aa:3a:57:1f:8f:
e6:4b:09:3f:7a:9e:5e:47:ab:a0:2f:98:5a:b1:40:
8c:23:1c:5b:97:bc:43:eb:19:07:11:cf:a8:41:d2:
04:bc:11:e1:3b:44:58:1e:01:d1:ff:fe:4c:f8:69:
15:6b:ee:3a:21:47:a8:59:89:3b:e3:f4:61:5f:dd:
7f:1f:66:23:38:24:80:6f:4b:94:cf:c8:a7:a1:6f:
52:7f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
76:D6:DE:F8:A7:92:5E:1D:45:AE:AA:58:56:B3:36:72:44:E8:62:81
X509v3 Authority Key Identifier:
keyid:76:D6:DE:F8:A7:92:5E:1D:45:AE:AA:58:56:B3:36:72:44:E8:62:81
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
85:e2:7f:5d:ce:91:e7:68:60:28:96:5d:76:26:f7:2d:64:dd:
f7:6a:19:c9:b5:b8:4f:40:7a:c4:76:be:ef:cd:a0:66:03:69:
61:45:e2:40:ba:75:ca:ec:78:e9:bb:ca:1b:89:44:0c:43:f3:
15:a6:cc:9f:0d:d5:bf:f8:58:2b:18:94:7a:5b:7e:c2:24:01:
4d:d2:d5:f1:6f:08:a1:9e:60:4c:4a:18:9a:a1:93:75:60:84:
9d:af:54:6a:99:2c:94:e1:8f:58:5e:82:01:b8:c0:e7:2a:8e:
13:0f:a5:a6:58:72:a2:1b:fa:c5:3f:fe:db:85:bd:0b:78:9b:
60:f0:74:fc:ce:31:d0:08:cf:eb:0c:4b:14:ca:0d:96:26:15:
b5:d2:f7:9b:f7:c6:f9:d2:24:e3:ef:2c:dc:fb:b0:43:ac:b4:
70:2d:20:b5:22:6f:3e:ba:68:c2:f5:e3:bb:e2:75:59:0f:eb:
fa:76:39:a6:24:d0:4d:6c:27:c0:a0:db:26:94:ff:39:f8:a2:
fc:0e:5f:a8:d5:fe:da:15:5b:70:68:3c:e9:e6:0d:01:a7:bb:
36:cd:2f:ef:1a:a7:f6:13:2c:01:ae:0e:24:d4:a2:1c:d0:3d:
88:5b:6d:ec:77:99:aa:48:f7:26:8d:84:21:b6:74:26:89:a8:
eb:e5:d7:fa
Checking of the private key openssl gave me this:
openssl rsa -in /home/torino/Desktop/privateKey.key -check
RSA key ok
writing RSA key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA2xdKGCnNEsh3iUueIfHUygptfHH5qDwxEdJLSF2rvvqbRMDp
+ybBMn+mCThz6RhzVnpeMUx0K8Zm+l/Cq0qEcoYW/P2kXht09bRXM9SuCoOCu2Yp
zgD4Xvwok3jC8ww+aT9KJyVHOmwBYwdYpfSPET4pz/wZqzCbl9fSb6KJEhRldIu9
793AOzBsLb5IGsBGQav6qDm4y7vgY4njpk+jTI5SXEXteYCnjr3MJrvLqjpXH4/m
Swk/ep5eR6ugL5hasUCMIxxbl7xD6xkHEc+oQdIEvBHhO0RYHgHR//5M+GkVa+46
IUeoWYk74/RhX91/H2YjOCSAb0uUz8inoW9SfwIDAQABAoIBAQDTk20ZYpzJK9DM
RLskOr7skh9jU0nunpoghL3w14y49JinT8lloepm0wDL3LmK+/K+K5P09ckmUQY3
eeyrsF2xny5qCKQHwWo0sYCY7CVav9+rC6EJcMRqLgcdSzywrD1FNDpvDT/4+j5o
nLqOIVtcInUMhn9fY6SOgXyWFBdc3Y3KPcW1ht2Cjp1cWRsqNUGR1tlSKhtcwNZR
pQPD5gma6/ky0cKIMxcTfZUgsdpcD4S6D99A6v70WFwg6HzUcgxTlnBEln0QESlF
dveY6bZpJ8MpObsiqcJBpgdYwVjl2IHf+4qYZeWLTe540GUE1jLlpDNQAl2AYGyV
BpLg1GK5AoGBAPZm1ujKUwJHNcPx7sDT6FrpXliK8b0YZYtdCxFWnJYHSCufi6Ta
4KSxZF9AdxFssYn5agXTZ1k6aW0VOW74TSyfZ8/AA9SH2jiDjC8F0wSDr+CBAw64
f88tI/6Q1JlsbaowaaDcr54SnqxO0gZjhnuWkj+U6SqiDnMbkMl78XStAoGBAOOg
Gj1HPfcEbewI9sMh50M9s7oQfD3dN7tdRzXH3Peswuq6NTU3WvR1UagXi0E6dOjC
7mtiKCbBCGCPqL1BijzGR7J6FYxB7hnkE53vByWleYf2c8EQO1Gg9zleFRXxcpy2
VCJMazsGmY7QpuWC/77Q0a9V81VOI5u3uXz3GF1bAoGAWBkc7c6pLz9WseBmhPs/
MIIQAYhsNjfq1pFFy8Uz51BjNXWt8BtyBnCGeqgJ6mj6cWKDzeFwKi8AUsgr6MlO
jo3QCC+XLv4DwAEItidW815CG/sEpNbCm8h//hy6ZsCl1RvKKIG/KL1vjhwAa9hZ
1QZY8/LCC0Q19mH8uo1eH2ECgYA4HDA7qMMakAn0pCUH5uSWC7CxDf1CVrS1SAIU
vMa4euq1Z99T1ehi2ESfteYK1zkYY2zYJaMWIoFJJECJHo3P+2STF0sWfu4Njc5U
ISbW3dp+bH8OOU0WCyLGDm4OMa15+ev1ZHcOXssdjEuHyen3BIybtwk7nv5iFUDx
EAv+fwKBgFFsB9YR+pn7w53ndam06V8kGe5iFLvuz4DVaCmKtjbCEXu0JEGmUzKD
AKB1QXIvAZZSM8QVZFd//OI5BAO97IPxNtE6PuQayaNN7Dq2tiO5L9LOCuXqxXBb
4JDlQJG8yfcMAiMBCFFKZqjWo6sRclieVkeOi87v06Wx926tTfkR
-----END RSA PRIVATE KEY-----
And this means that the certificate and the private key are correct.
But when i try to have an gRPRC secure connection, I got this error on the client:
E1108 18:12:33.539123908 3109 ssl_transport_security.cc:1469] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
And the server gave me this error:
E1108 18:12:33.540418211 1963 ssl_transport_security.cc:1839] No match found for server name: 192.168.37.137.
Responding in case you're still having the issue or in case someone else finds this post. I've seen a similar error that was caused by missing SANs in the certificate used on the server. I believe you may need to add a SAN with value IP:192.168.37.137 to your certificate for it to work as expected.
1. openssl req -nodes -new -x509 -keyout server.key
2. vi san.conf # add lines shown below
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:TRUE
keyUsage = digitalSignature, nonRepudiation,
keyEncipherment, dataEncipherment, keyAgreement, keyCertSign
subjectAltName = IP:192.168.37.137
issuerAltName = issuer:copy
3. openssl req -new -key server.key -out server.csr
4. openssl x509 -req -in server.csr -signkey server.key -out server.cert -days 3650 -sha256 -extfile san.conf
5. openssl x509 -in server.cert -text
I have a very simple flask HTTPS server running using a self-signed certificate on a google compute instance. Here is the code for the server:
from flask import Flask
app = Flask(__name__)
with open("test_certificate.pem",'r') as inputFile:
print(inputFile.read())
if __name__=="__main__":
app.run(ssl_context=("test_certificate.pem", "test_key.pem"),
debug=True, host="0.0.0.0", port=443)
When I start the server I receive the following output:
-----BEGIN CERTIFICATE-----
MIID7DCCAtSgAwIBAgIJANdrMgD+3bUnMA0GCSqGSIb3DQEBCwUAMIGKMQswCQYD
VQQGEwJVUzELMAkGA1UECAwCUEExFTATBgNVBAcMDFBoaWxhZGVscGhpYTEKMAgG
A1UECgwBQTERMA8GA1UECwwIYXNkZmF3ZWYxFzAVBgNVBAMMDjM1LjIzMS4xMTAu
MTQ5MR8wHQYJKoZIhvcNAQkBFhBhc2RmYXNAZ21haWwuY29tMB4XDTE5MDMyMjIw
NTcyM1oXDTIwMDMyMTIwNTcyM1owgYoxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJQ
QTEVMBMGA1UEBwwMUGhpbGFkZWxwaGlhMQowCAYDVQQKDAFBMREwDwYDVQQLDAhh
c2RmYXdlZjEXMBUGA1UEAwwOMzUuMjMxLjExMC4xNDkxHzAdBgkqhkiG9w0BCQEW
EGFzZGZhc0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCl16hzFOqYQozHh4G46oY32HP59LgfbT7hGyAcYPC3jt42jiKa9Yfpa8JaaZrm
xWagPNZG73xqyejMoaLKEPbZc650e+mwNuVoer2ic2CZIKp5iVy0si85ecxAkFYR
3RF+eDCqL8kT5gLbfj8knq3PQtVp2AmNlnN8c3cV6It5XJMUoPyfGdCGzphzVha+
XBpWJ25pWmezB38lTZpBdeZx2KDTDNpbtxsmtxy52IHQ/HXCnlW8bSbvhFvTn0IH
q3vOJnKG7GNOiOtyi+i6bSg0QxbQAhN5xVVB3Qq6i5yaIFTz/1Wedr4FpvbJqShZ
wf5lt4PxSaO6hDXbnWOgiiW3AgMBAAGjUzBRMB0GA1UdDgQWBBSs3T312Qv3r7QN
bs/duHyQrvO9RTAfBgNVHSMEGDAWgBSs3T312Qv3r7QNbs/duHyQrvO9RTAPBgNV
HRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBLcpXBcafyR2SRa6jDDnwt
rDxr4aKnC6C99JPmrpBS6aD5+LrCUn6eY7B0MS5/+EoBEWxMtRoCW6MpBKdaOgPw
1etjfoYICPTvkvnIJRn3re1ziV54wSaXWlATTCoJ9Cjg8daHk7RS5JFr9T13iRwR
dzbAx6/dAFur6mmVcH5yD+qSJWSIBq/EpOjy4xWt1Pqu7oClzGLCStsR4sAIg0+T
gQIwxy9pMukxZOCzER9Ega+Wnac/CpA9pNUs+ayMebjo9ZVnq95vBzy87UMptvz9
W00TV+NN/zbnV24gmnOTWla4x8ylxxhq+7bYImZjnwinMe3FCIcZA350dcuOZI8n
-----END CERTIFICATE-----
I was having issues sending HTTPS requests (I was receiving SSL "bad handshake" errors), so I executed the following code to see what the certificate was that was being returned:
import ssl
serverSSL = ssl.get_server_certificate(('20.42.490.329',443))
print(serverSSL)
with open(VERIFY_PATH, 'w') as outputFile:
outputFile.write(serverSSL)
This code outputs the following:
-----BEGIN CERTIFICATE-----
MIIDmDCCAoCgAwIBAgIJT8O3F1rTZQgnMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJQQTEVMBMGA1UEBxMMUEhJTEFERUxQSElBMQ0wCwYD
VQQKEwRVUEhTMRYwFAYDVQQDFA1VUEhTX0ZJUkVXQUxMMB4XDTE5MDMyMjIwNTcy
M1oXDTIwMDMyMTIwNTcyM1owgYoxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJQQTEV
MBMGA1UEBwwMUGhpbGFkZWxwaGlhMQowCAYDVQQKDAFBMREwDwYDVQQLDAhhc2Rm
YXdlZjEXMBUGA1UEAwwOMzUuMjMxLjExMC4xNDkxHzAdBgkqhkiG9w0BCQEWEGFz
ZGZhc0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3
Bd7d0ty9wbw8G+ongIs6Ezy0njO0JLulMNV/SVnBg+V0yHfCy0emA4JXyHTw+LfX
fQcQeiv0znXUFNnl+i2T0vQuPb2U99wbj+c/MEsiP+H9NRDWzgYgQTat/nGZv31l
grH4+IJSYVuQ/iKquSseKrQRJzDQes1BbuA8hNoD2iIuV2hIPzXMUOEbBExXoAF8
U8M0UMWUrvsCYrzf/qJlg+jciUqhXiRc3SomIxrs6P7J/LJHl+xWFsUflWgzoxDn
NCYaf3nCGi55cqWbstJytvtDoDqS3+HoYeCLz3ab/HCGMiTPJOtLi/nLMhkCZy2U
bowedqlFX6C7wIG/rczTAgMBAAGjMjAwMB0GA1UdDgQWBBSs3T312Qv3r7QNbs/d
uHyQrvO9RTAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBtgJZ3
dQMV36kXDKKEBEV04RTFD6XrKhEx0/TRyiCzuCG05GtF0efbA0pz18uDMNYla70i
R4n/KWTRjbJ8aVvQwYvT7vCgTzHtM0lPwIiZYzssvlaauBEiZCBYAEV1hFEK53A2
eqUmDGul7x9w4IO0800pC8vkdxL6UGa6i/cEp4xXZca+A4Ukhoq+I8sENPTiBIy1
FT+wWgz8d7V65wM+r9pe4OvUubLJ4qHwKBGRGCOAh5SeluKIL1L8sSul3MKOr+Cj
t5mHuGsjXTyIjB3nYkW94tBkFiRvEYRKtvoDOo5wm8v4g/GGSZtDlNLtq7523J3n
maGrCR2AQw4PA5i3
-----END CERTIFICATE-----
Why do these certificates not match? I am assuming this is why I am getting the bad handshake error. Any suggestions are much appreciated
Ok, so you are using invalid certificates, and the reason why the file changes every time is that you are corrupting it.
This is what I use to get a TRUSTED certificate that most browsers can use: https://certbot.eff.org/instructions. Comment and tell me if this works for you.
Tho, if you really want to test this, just use
if __name__ == "__main__":
app.run(ssl_context='adhoc')
I'm trying to update a new valid SSL cert provided by DigiCert on my python flask. The same code with the old expired cert works just fine. However for the renewed cert, it did not recognise my certificate chain and giving error:
[root#test~]# openssl s_client -connect somedomain.com:9443
CONNECTED(00000003)
140340901406536:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:744:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
The weird thing is, when i'm using openssl command to verify my cert chain, everything is working well as follow:
[root#test ~]$ openssl verify -verbose -CAfile CertChain.crt Server.crt
Server.crt: OK
This is my python code
from OpenSSL import SSL
from flask import Flask, send_file, make_response, request, jsonify, Response
from flask.ext import restful
from flask.ext.restful import reqparse, abort, Api, Resource
#------------#
context = SSL.Context(SSL.SSLv23_METHOD)
context.use_certificate_file("Server.crt")
context.use_privatekey_file("Server.key")
context.use_certificate_chain_file("CertChain.crt")
context.set_options(SSL.OP_NO_SSLv3)
context.set_options(SSL.OP_NO_SSLv2)
context.set_cipher_list('ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS')
app = Flask(__name__)
#app.route("/")
def hello():
return "Hello World!"
if __name__ == "__main__":
app.run(host='0.0.0.0', port=9443, debug=True, use_reloader=False, ssl_context=context)
And for your info key and certificate is matching with no problem
[root#test]# openssl x509 -noout -modulus -in Server.crt | openssl md5
(stdin)= adc3de807ec6a02c5ba9da89f3fe5dd5
[root#test]# openssl rsa -noout -modulus -in Server.key | openssl md5
(stdin)= adc3de807ec6a02c5ba9da89f3fe5dd5
Is there anything affecting this? Python version? OpenSSL version? My cipher? Any body can help? Thanks
SSL handshake has read 7 bytes and written 249 bytes
These are not problems of the validation of the certificate.
The clients starts the SSL handshake but the server sends only 7 bytes back, which might be an SSL alert that something is wrong. The server never sends the certificate back so it cannot be a problem of the client side validation.
This means you should better check the server side for problems and not the client side. And since you say that exactly the same code works with the old certificate it can not be a problem of protocol version or ciphers but must relate to the certificate. My guess is thus that the private key you use does not match the certificate you use, which gets not checked when you do the openssl verify.
I got the solution. Previously my certificate chain only contains the Intermediate and Root certificate which is not complete.
The solution is to also include the server certificate into the chain which is weird since context.use_certificate_file is already defined.
Anyways, the handshake is now working fine. Thanks!
I'm trying to use imaplib.IMAP4_SSL function but I'm stuck with this error:
[Errno 336265225] _ssl.c:356: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
try:
mail = imaplib.IMAP4_SSL(host='imap.gmail.com', port="993", certfile="certIMAP.pem")
except Exception as e:
print e
sys.exit()
The certificate has been downloaded with:
echo | openssl s_client -connect imap.gmail.com:993 2>/dev/null | openssl x509 > certIMAP.pem
Permission on the file are ok.
If I use the keyfile option, they ask me the cert, and then the same error is obtained.
I could not find example for this function with cert specification.
Thank you.
While it is not obvious from the documentation I would suggest that the parameters certfile and keyfile are not used to verify the servers certificate (that's how you use it - and keyfile would not make any sense here) but are the optional certificate for the client and it's private key, which some server might require to identify the client (e.g. instead or additionally to password).
To verify the server you usually have something called CA file or CA path (CA = certificate agency) and you don't need a private key here. There seem to be no obvious way for given the CA certificates here, but Certificate Authority for imaplib and poplib python might help you with this.