Recently, I bought a PositiveSSL certificate from Namecheap. I've been wanting to apply them to my website for use with iRedMail and WordPress, but I've had no luck doing this.
I received a ZIP file containing four files, and I don't understand what to do with them.
The four files are:
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
www_mydomain_com.crt
My current settings in Postfix main.cf for SSL are:
smtpd_tls_key_file = /etc/pki/tls/private/iRedMail.key
smtpd_tls_cert_file = /etc/pki/tls/certs/iRedMail_CA.pem
# smtpd_tls_CAfile =
My current settings in Dovecot dovecot.conf for SSL are:
ssl = required
verbose_ssl = no
#ssl_ca =
ssl_cert = </etc/pki/tls/certs/iRedMail_CA.pem
ssl_key = </etc/pki/tls/private/iRedMail.key
I'm assuming I'm meant to change these entries to accommodate the new certificates, but I just don't know how to set this up at all.
I have the .key and .csr files from when I generated the certificates, as well.
Can anyone help me out here? I've never had to set all of this up (and I'm a bit of a Linux novice), so I'm at a complete loss here. Also, I'm running Scientific Linux 6 64bit, if that makes any difference. I don't have any GUI (like cPanel) set up, either.
Thank you in advance.
I don't understand what to do with them.
* AddTrustExternalCARoot.crt
* COMODORSAAddTrustCA.crt
* COMODORSADomainValidationSecureServerCA.crt
* www_mydomain_com.crt
You need to build a certificate chain for the server to serve. You can't just send the end-entity (server certificate). Here's how you do it with the files that were provided to you.
Ignore this one. Its the CA, and the client must already have it and trust it:
AddTrustExternalCARoot.crt
Concatemate these three into a single file, in this particular order. Call it something like www_mydomain_com_chain.pem:
www_mydomain_com.crt
COMODORSADomainValidationSecureServerCA.crt
COMODORSAAddTrustCA.crt
After concatenation, the file should look like:
-----BEGIN CERTIFICATE-----
<server certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediate certificate>
-----END CERTIFICATE-----
Plug the file with the concatenated certificates into smtpd_tls_cert_file.
You can test you rig with the following. It should finish with a message similar to Verify Result 0 (Ok).
openssl s_client -connect <server>:465 -CAfile AddTrustExternalCARoot.crt
Note: for testing, its important to pick a mail port that transport over SSL/TLS, like 465 or 995. Its easier than trying to coordinate a -starttls option within s_client.
Related: COMODORSADomainValidationSecureServerCA.crt is really an intermediate certificate. You can find it at [Intermediate #2 (SHA-2)] Comodo RSA Domain Validation Secure Server CA.
Related: COMODORSAAddTrustCA.crt is really an intermediate certificate. You can find it at [Intermediate #1] COMODO AddTrust Server CA.
Related: someone had a similar issue recently using Comodo's gear. See SSL site and browser warning.
The server is once again using the configuration provided above, and the domain is "www.lildirt.com". Again, I ran a check using DigiCert's tool, and it's still saying I'm using my old self-signed certificate (that expires in 10 years), but I've changed the settings above.
OK, your mail server is mail.lildirt.com:
$ dig lildirt.com mx
; <<>> DiG 9.8.5-P1 <<>> lildirt.com mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27746
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;lildirt.com. IN MX
;; ANSWER SECTION:
lildirt.com. 1799 IN MX 10 mail.lildirt.com.
;; Query time: 109 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Mon Aug 11 18:33:49 EDT 2014
;; MSG SIZE rcvd: 50
Now, check it with OpenSSL. You don't have Secure SMTP running:
$ openssl s_client -connect mail.lildirt.com:465 -CAfile AddTrustExternalCARoot.crt
connect: Connection refused
connect:errno=61
And you don't have SSL/TLS enabled on 995 (or 587 and 993 for that matter):
$ openssl s_client -connect mail.lildirt.com:995 -CAfile AddTrustExternalCARoot.crt
CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
...
And this is a problem:
$ telnet mail.lildirt.com 25
Trying 107.178.109.102...
telnet: connect to address 107.178.109.102: Operation timed out
telnet: Unable to connect to remote host
Is Postfix even running?
The server is once again using the configuration provided above, and the domain is "www.lildirt.com". Again, I ran a check using DigiCert's tool, and it's still saying I'm using my old self-signed certificate
Why are you running a tool against www.lildirt.com:443? The problem you presented is for Postfix and a mail server configuration. www.lildirt.com has nothing to do with your question.
If interested, you don't need web based tools. OpenSSL gives you everything you need to know:
$ openssl s_client -connect www.lildirt.com:443
CONNECTED(00000003)
depth=0 C = CN, ST = GuangDong, L = ShenZhen, O = mail.lildirt.com, OU = IT, CN = mail.lildirt.com, emailAddress = root#mail.lildirt.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = CN, ST = GuangDong, L = ShenZhen, O = mail.lildirt.com, OU = IT, CN = mail.lildirt.com, emailAddress = root#mail.lildirt.com
verify return:1
...
And:
$ openssl s_client -connect www.lildirt.com:443 | openssl x509 -text -noout
...
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 17052364516268315109 (0xeca62b2e24a611e5)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=CN, ST=GuangDong, L=ShenZhen, O=mail.lildirt.com, OU=IT, CN=mail.lildirt.com/emailAddress=root#mail.lildirt.com
Validity
Not Before: Jun 1 21:42:41 2014 GMT
Not After : May 29 21:42:41 2024 GMT
Subject: C=CN, ST=GuangDong, L=ShenZhen, O=mail.lildirt.com, OU=IT, CN=mail.lildirt.com/emailAddress=root#mail.lildirt.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9a:53:ff:41:29:4f:41:01:62:40:1b:8d:98:81:
50:21:7a:c9:d6:29:fb:1d:67:68:de:9f:22:b9:36:
23:56:c4:75:aa:44:75:29:2b:84:9f:0b:0a:e4:d3:
4d:a1:94:8c:04:a4:35:f4:fa:03:1a:46:28:8c:a4:
c5:63:76:72:92:f1:a5:f8:75:cc:61:64:5b:c4:12:
70:a6:d0:da:62:b9:f2:d0:b9:65:d8:06:d9:aa:40:
21:fb:2b:df:12:e2:d3:7c:a9:0e:4e:d3:91:21:2d:
ad:d1:9c:1a:bf:fd:38:05:ef:9c:6e:61:2f:f9:22:
75:94:b1:2a:29:8b:45:b0:aa:fe:31:f3:32:9d:ce:
cc:2d:5d:e9:c6:0a:06:37:fd:ce:5d:09:1c:bf:98:
b7:d5:cc:2a:2f:e3:ba:79:a4:54:4e:70:de:dd:49:
e6:71:27:eb:14:ed:80:e1:bc:ab:04:c9:73:90:8d:
91:a7:c5:73:16:22:3d:a6:3b:84:5b:0e:a7:ec:1e:
67:c4:59:d9:76:17:37:16:02:94:d7:eb:82:e6:ae:
93:04:92:d7:2b:b4:6f:8a:d4:2b:64:77:9f:89:30:
34:a2:99:4a:f9:ac:d0:ec:c0:e0:0d:34:dc:03:53:
1e:35:96:4d:15:aa:46:70:b5:11:aa:41:84:84:00:
bc:2d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
1A:6C:14:8A:E0:6F:7D:D9:80:BF:9A:80:A4:16:11:D4:C7:83:07:FB
X509v3 Authority Key Identifier:
keyid:1A:6C:14:8A:E0:6F:7D:D9:80:BF:9A:80:A4:16:11:D4:C7:83:07:FB
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
4b:78:ac:8d:09:a0:c1:a0:66:66:c6:6c:4e:40:75:a8:00:08:
d6:be:31:f3:0f:48:7c:2d:ed:c6:2e:b9:39:06:38:66:a3:68:
23:0a:d6:11:cf:2c:9d:18:60:37:25:a2:24:0f:9c:4a:2a:09:
cc:e0:5b:36:3b:0d:47:01:47:6e:11:5a:7e:0d:9e:aa:7d:1b:
41:3e:37:2f:b5:72:45:62:8f:cf:6f:27:d6:6f:5b:1c:bc:c7:
9a:10:85:41:6c:c9:2f:7f:c6:b5:eb:cc:8c:ca:33:4a:83:ab:
7a:fd:6b:dc:23:44:79:79:3b:8e:dd:de:77:d6:8e:e7:06:28:
53:66:b9:96:ef:ad:04:7e:dd:23:99:6e:d8:9e:c5:3a:d9:ef:
25:be:ee:90:f4:47:16:17:16:fe:37:da:f4:a9:cd:8c:54:47:
ad:ed:ce:30:69:23:ee:58:23:bb:8f:db:0a:b7:4f:fb:00:95:
34:c2:25:3a:37:20:2b:7d:3a:19:1c:ad:75:29:4e:f5:cb:de:
8d:98:54:e7:f4:1c:24:a8:62:b2:0b:3e:71:2d:1a:b9:98:59:
ca:66:ac:68:a7:a0:0a:da:8f:35:8c:d1:ba:33:1f:a4:39:bc:
fd:58:a3:67:4d:eb:c2:00:9c:36:9a:a7:58:2c:2a:f1:38:c9:
13:74:e0:04
From above, (1) no DNS names in Common Name (its deprecated by both the IETF and CA/Browser Forums); (2) CA:FALSE (not TRUE since you are not issuing certificates); (3) add DNS names to Subject Alternate Names (required by CA/Browser Forums).
See SSL Certificate Verification : javax.net.ssl.SSLHandshakeException on how to issue a self signed with the proper attributes and multiple DNS names in the Subject Alternate Name (SAN).
Here's an example for armor-cloud.com. This is what its supposed to look like for Secure IMAP on port 993. You should get nearly similar results assuming you provide Secure IMAP. The difference is the domain and the CA. Notice the command finishes with Verify Return Code: 0 (ok).
$ openssl s_client -connect mail.armor-cloud.com:993 -CAfile startcom-ca.pem
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/CN=mail.armor-cloud.com/emailAddress=webmaster#armor-cloud.com
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGTDCCBTSgAwIBAgIDEMlWMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MSBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTQwNTI5MjIzODQy
WhcNMTUwNTMwMDYzMDAwWjBWMQswCQYDVQQGEwJVUzEdMBsGA1UEAxMUbWFpbC5h
cm1vci1jbG91ZC5jb20xKDAmBgkqhkiG9w0BCQEWGXdlYm1hc3RlckBhcm1vci1j
bG91ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCSL72lQJya
JQ6vvXQpWUzAjOxuI+5u2bmBmblc7AoFDwOoFozg1aEUz5B7q/9DcJZpX8eF76JG
3E/zoU8s7pq30U1LAbg3d7Rg5OTc8bJd21BdUz8Bt3OctFxTKhddYpSkM3LjGEuR
9tRzTCY/KDFglZMBDoz4iJdHFTL3WaCCuvulaanz/zMFx2Kp4p9Jep8/BR4OtfOx
8RexSVwmjXm+CmN6npBl2cl3Li4XUKqfr9uMD24cNgom/Plt3lq4FQpGsb8k29S0
6JMJYpKXFVM/XGKNI8g3aQdxi3daQiTgngtw8r7n8nHUTIOIl/kg3dfDwSYW6sE/
LyXfjYl+XY2/AgMBAAGjggLqMIIC5jAJBgNVHRMEAjAAMAsGA1UdDwQEAwIDqDAT
BgNVHSUEDDAKBggrBgEFBQcDATAdBgNVHQ4EFgQUqOXcMohVao8F4j9YVhdZj98N
WxkwHwYDVR0jBBgwFoAU60I00Jiwq5/0G2sI98xkLu8OLEUwMAYDVR0RBCkwJ4IU
bWFpbC5hcm1vci1jbG91ZC5jb22CD2FybW9yLWNsb3VkLmNvbTCCAVYGA1UdIASC
AU0wggFJMAgGBmeBDAECATCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcC
ARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUH
AgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB
vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENs
YXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENB
IHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug
aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4w
NQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0MS1j
cmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9zZXJ2ZXIvY2EwQgYIKwYBBQUHMAKG
Nmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuc2VydmVy
LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ
KoZIhvcNAQELBQADggEBAGN4+kuLiZdUVgNL2cjLLv5IeLhq5Ly35BKJ8SohkKdM
B2cWOC3r+iFohxRI+VvILOwh7GCuWsWWJLOd17klgWf3EF7EkYFyR4PB6m71BdRD
RTNDXw27Xw0lADMBP36f28lo8X26EJbpav7MVNK9gqbdHU/dEYfY34S9li/iXe2n
E7Resh/vPEmFuebSrpHrfUT5fWWsbZKWcEZOWJwd8nqztI/7TdI63H9O1BgrCxQ/
lL+t9HsRfoh7EjEmjYy7O4q1oFAa0RmYvsikhVJo++6gsyPKHcOKzb65RWb2RTiM
lzbvqlg3+XplAdVzzqC+M0C5JHeIXAZosWTmkgDGPHU=
-----END CERTIFICATE-----
subject=/C=US/CN=mail.armor-cloud.com/emailAddress=webmaster#armor-cloud.com
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3524 bytes and written 626 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384
Session-ID: E6CD57CF3A522AC3093C3A734EE8C8369F8ECD5A0C1206FB77184D481910B9B8
Session-ID-ctx:
Master-Key: 5DC080AC9627E8294A2C675D5177BFDC25B897371FEA36944CB60181B4C39D15E284DCB04A174AECCB41175430FFBFF3
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 29 80 70 c1 ea 19 57 e3-25 5b ee eb 12 39 f8 c3 ).p...W.%[...9..
0010 - 97 c6 38 82 cd 4e a2 5d-ba b9 06 5f 4f 62 25 34 ..8..N.]..._Ob%4
0020 - a1 6b 49 04 8a 8b 9f d2-e7 3c 0d 63 70 ae dc aa .kI......<.cp...
0030 - 9f d5 a1 d1 e4 26 01 bb-0e 1a f7 7f 35 0e af 6b .....&......5..k
0040 - 28 70 be e0 d3 4f 93 62-c8 2c 2c 43 2a 32 71 f3 (p...O.b.,,C*2q.
0050 - 4a 1b 5a 35 4c d5 e2 e6-ad c1 65 18 42 4b 67 89 J.Z5L.....e.BKg.
0060 - 8b 97 95 dd cf 0f 3e b1-32 6e 52 a0 77 9c 86 cc ......>.2nR.w...
0070 - 47 39 b4 66 60 33 74 12-b1 25 a5 4e 71 0d 60 e5 G9.f`3t..%.Nq.`.
0080 - 79 8f a3 9c 06 a1 5b cc-a3 f7 c4 bd f4 86 77 0c y.....[.......w.
0090 - 5f 24 57 38 06 fa a2 34-57 e7 64 56 ce 73 24 ad _$W8...4W.dV.s$.
Start Time: 1407799533
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
* OK IMAPrev1
Related
Hi I am trying to use openssl command to test my server code written in python using aiosmtpd library.
Here is the server side code I have written:
import datetime
import sys
import ssl
import aiosmtpd.controller
class SMTPServer:
async def handle_DATA(self, server, session, envelope):
# some printing of the response
return "250 OK"
if __name__ == "__main__":
handler = SMTPServer()
context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context.load_cert_chain('cert.pem', 'key.pem')
controller = aiosmtpd.controller.Controller(handler, hostname="localhost",port=587,ssl_context=context)
controller.start()
input('Running smtp Server over TLS on port 587. \n')
controller.stop()
When I try to execute above code with command openssl s_client -debug -starttls smtp -crlf -connect localhost:587 I am getting the below error
$ openssl s_client -debug -starttls smtp -crlf -connect localhost:587
CONNECTED(00000003)
read from 0x55feaf0ba7c0 [0x55feaf0be780] (4096 bytes => 0 (0x0))
write to 0x55feaf0ba7c0 [0x55feaf0bf790] (23 bytes => 23 (0x17))
0000 - 45 48 4c 4f 20 6d 61 69-6c 2e 65 78 61 6d 70 6c EHLO mail.exampl
0010 - 65 2e 63 6f 6d 0d 0a e.com..
read from 0x55feaf0ba7c0 [0x55feaf0be780] (4096 bytes => 0 (0x0))
Didn't find STARTTLS in server response, trying anyway...
write to 0x55feaf0ba7c0 [0x7ffd8edd5fb0] (10 bytes => -1 (0xFFFFFFFFFFFFFFFF))
read from 0x55feaf0ba7c0 [0x55feaf0b1f80] (8192 bytes => 0 (0x0))
write to 0x55feaf0ba7c0 [0x55feaf0ccf00] (283 bytes => -1 (0xFFFFFFFFFFFFFFFF))
write:errno=32
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 23 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x55feaf0ba7c0 [0x55feaf0b1f80] (8192 bytes => 0 (0x0))
could anyone please support how to resolve this error? If I use
openssl command without adding -starttls like "openssl s_client -debug -connect localhost:587" then the above server code is working fine. But I want to make it work using -starttls along with openssl command.
I am trying to push my docker image to Google Cloud Registry but get a 509 error say the certificate signed by unknown authority. This never used to be a problem and I can't seem to fix the issue. Any help is appreciated.
I'm running
docker -- push gcp.io/project/registry
Error
Get https://gcp.io/v2/: x509: certificate signed by unknown authority
I'm on Mac OS.
Update: you have a typo, you need to go to gcr.io, not gcp.io.
[ Original answer ]
Looks like a certificate issue on gcp.io:
$ openssl s_client -showcerts -connect gcp.io:443 </dev/null
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.gcp.io
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.gcp.io
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.gcp.io
i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
-----BEGIN CERTIFICATE-----
MIIF6jCCBNKgAwIBAgIRAPLbl+CLddoCWmMcKSzPAT8wDQYJKoZIhvcNAQELBQAw
gY8xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD
QTAeFw0xOTExMjUwMDAwMDBaFw0yMDExMjQyMzU5NTlaMFUxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEdMBsGA1UECxMUUG9zaXRpdmVTU0wgV2ls
ZGNhcmQxETAPBgNVBAMMCCouZ2NwLmlvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAozq94VQqkxLR0qUqz6IM5/lY411MkLgrQhOR8Sg17EioEpudFKCV
FhC9N2Z8EFLpaGAxABpYM5JLWy1PpszOEETFswaS0Y/CpCnzW/SXtlH2ZOlGBXII
3LKP7ScfCgbwnndg820cA0XDNc54MUZcx2ebe2MZfFHKNhm+Lpqr4UZZu4ZaE8C6
9tcJaMC/znIWUpf+61aUJIQTYITL+NVB3zCeDhK0r29aLbz4K33TqN+9PJtwyTiS
8PZFTg93R8RCzdJD6x1lg3u7tAHGi6S3Omn7y3YtivTsA3iYbYIBm9i+0EHgpTOA
Hp9Z3wX2TF/M6FiY7yo1tc8ft6i3wICaUwIDAQABo4ICeDCCAnQwHwYDVR0jBBgw
FoAUjYxexFStiuF36Zv5mwXhuAGNYeEwHQYDVR0OBBYEFH7PsGxNUFi1gLyOjwje
oEXcFIIuMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjBJBgNVHSAEQjBAMDQGCysGAQQBsjEBAgIHMCUw
IwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMAgGBmeBDAECATCB
hAYIKwYBBQUHAQEEeDB2ME8GCCsGAQUFBzAChkNodHRwOi8vY3J0LnNlY3RpZ28u
Y29tL1NlY3RpZ29SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EuY3J0
MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAbBgNVHREEFDAS
gggqLmdjcC5pb4IGZ2NwLmlvMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDwAHUAB7dc
G+V9aP/xsMYdIxXHuuZXfFeUt2ruvGE6GmnTohwAAAFuouNwEgAABAMARjBEAiAB
bpCCsd9bTM4mJMAEVf9WL4Mu3z+EaezOfJ+1N5MzEAIgHcuRkKk/tukyDAz0gZtu
z1K87zVaw96FUdFbLQnZw0YAdwBep3P531bA57U2SH3QSeAyepGaDIShEhKEGHWW
gXFFWAAAAW6i42//AAAEAwBIMEYCIQCL81nEy3BBlmVR5ehK+LgAvWUxlwWUoTtH
+TLgft+usgIhALCoeeBaEkcMTPIU+fmQQ6FTp7tMvzN726bHJ/ODJZmEMA0GCSqG
SIb3DQEBCwUAA4IBAQBBnaYdC4OjT0rjlVYRR5lqiRsHTgQiReJXVwXtYO6czPYU
np1szzpF0xto3lTImJNzyyWl8Zt+4H/ABrOE3aKlnpQVZ/nBPqx8cLI/O8kEl6o4
rQxCXfVum3LTHqO0EtFSQfC3ALS137afCKUGa/e4PlFNTMqStP/anhv6byK+0bwh
jiqd9xuhjLmttf6zDelcmZPAZFuSL34khKnILPiXBsbiKFULiY1yEdpc4IpNLvZD
ys46g64+ss0sIqYR3vDPdoQmY3SUutxL7m2fwElGKGJIMFvkJ4+TUvNqAIsyQuEt
sIp/puDi8aEFhExywY1zrAeUuj4CJrCsHKZ25IIg
-----END CERTIFICATE-----
1 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
i:C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
-----BEGIN CERTIFICATE-----
MIIFdzCCBF+gAwIBAgIQE+oocFv07O0MNmMJgGFDNjANBgkqhkiG9w0BAQwFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoXDTIwMDUzMDEwNDgzOFow
gYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK
ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYD
VQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sIs9CsVw127c0n00yt
UINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnGvDoZtF+mvX2do2NC
tnbyqTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQIjy8/hPwhxR79uQf
jtTkUcYRZ0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfbIWax1Jt4A8BQOujM
8Ny8nkz+rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0tyA9yn8iNK5+O2hm
AUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97Exwzf4TKuzJM7UXiV
Z4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNVicQNwZNUMBkTrNN9
N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5D9kCnusSTJV882sF
qV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJWBp/kjbmUZIO8yZ9
HE0XvMnsQybQv0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ5lhCLkMaTLTwJUdZ
+gQek9QmRkpQgbLevni3/GcV4clXhB4PY9bpYrrWX1Uu6lzGKAgEJTm4Diup8kyX
HAc/DVL17e8vgg8CAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTv
A73gJMtUGjAdBgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rIDZsswDgYDVR0PAQH/
BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4
dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0
dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggEBAJNl9jeD
lQ9ew4IcH9Z35zyKwKoJ8OkLJvHgwmp1ocd5yblSYMgpEg7wrQPWCcR23+WmgZWn
RtqCV6mVksW2jwMibDN3wXsyF24HzloUQToFJBv2FAY7qCUkDrvMKnXduXBBP3zQ
YzYhBx9G/2CkkeFnvN4ffhkUyWNnkepnB2u0j4vAbkN9w6GAbLIevFOFfdyQoaS8
Le9Gclc1Bb+7RrtubTeZtv8jkpHGbkD4jylW6l/VXxRTrPBPYer3IsynVgviuDQf
Jtl7GQVoP7o81DgGotPmjw7jtHFtQELFhLRAlSv0ZaBIefYdgWOWnU914Ph85I6p
0fKtirOMxyHNwu8=
-----END CERTIFICATE-----
---
Server certificate
subject=OU = Domain Control Validated, OU = PositiveSSL Wildcard, CN = *.gcp.io
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: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3435 bytes and written 424 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
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-AES128-GCM-SHA256
Session-ID: A1FB2B7B405094705F0DAFCAABA63B4E1ABDE5C122F2F3E5A7DE88ECB75AB617
Session-ID-ctx:
Master-Key: A0FB112FC9A33BD96E2346627A4E99A03F5C8AA404B19215EA3226A487B034E17EAC38AE0BD79C6B51E882BDC0DECE90
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1588527367
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
---
DONE
And I see a similar error from curl -v https://gcp.io/v2/. This will need to be resolved by Google.
For the same cacert.pem openssl returns different results.
certificate verification fails in Redhat linux 8 but successfully verifies in Redhat linux 7.5
[rhel8]: openssl verify cacert.pem
C = NO, L = Asker, O = E1, OU = ETO TER, CN = ETO Opto Certificate Authority
error 18 at 0 depth lookup: self signed certificate
error cacert.pem: verification failed
RHEL 7.5:
[rhel7.5]: openssl verify cacert.pem
ca-certs.pem: C = NO, L = Asker, O = E1, OU = ETO TER, CN = ETO Opto Certificate Authority
error 18 at 0 depth lookup:self signed certificate
OK
In your case (a self signed cetificate), the 2 versions of openssl do not return the same code.
OpenSSL 1.0.2 returns 0
OpenSSL 1.1.1 returns 2
This is documented in the changelog:
Changes between 1.0.2h and 1.1.0 [25 Aug 2016]
[...]
*) Make openssl verify return errors.
Your version 1.0.2k is on the branch 1.0.2, and behaves as in 1.0.2h.
When creating a Webhook in GitLab 11.0.2 and testing it, I get this back this error:
Hook execution failed: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert internal error
The Webhook URI is using HTTPS with a public certificate (not self signed).
SSL verification is disabled for this Webhook.
Update
I upgraded openssl1.0.2g to openssl1.0.2o but the error remains.
Then I tried to run:
openssl s_client -connect mywebhookhost:443
That resulted in:
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
verify error:num=20:unable to get local issuer certificate
Update 2
/opt/gitlab/embedded/bin/ruby -ropenssl -e 'puts OpenSSL::OPENSSL_VERSION'
returns
OpenSSL 1.0.2o 27 Mar 2018
Update 3
GlobalSign CA certs are installed
awk -v cmd='openssl x509 -noout -subject' '
> /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep GlobalSign
results in
subject=OU = GlobalSign ECC Root CA - R4, O = GlobalSign, CN = GlobalSign
subject=OU = GlobalSign ECC Root CA - R5, O = GlobalSign, CN = GlobalSign
subject=C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
subject=OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
subject=OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
From this thread, it looks like your openssl is too old
Have been fighting with TLS for a few days, realised my GitLab was running on an old debian8, upgraded to debian9. So now.
python -c "import ssl; print ssl.OPENSSL_VERSION"
OpenSSL 1.1.0f 25 May 2017
So start checking/upgrading openssl, for your webhook script to run properly.
I have the same problem and to solve that i need to install root certificates on gitlab server.
See here how to.
I am working on a use-case where OpenPGP is being used to generate a public key pair on a smart card (Yubikey).
The smart card is then to be shipped off to the user.
Trying to emulate this locally the following is being done:
generate keys on smart card
remove GnuPG home directory
access smart card to re-generate GnuPG home directory
The issue is that I cannot test encrypting a file after the above steps have been performed as the public key seems to be missing. fetch doesn't seem to work.
At this stage I do not want to share the public key on any online server.
Is there any way of retrieving the public key from the smart card after deleting the key rings?
Below are the steps being followed:
$ gpg --card-edit
Reader ...........: 1050:0404:X:0
Application ID ...: D2760001240102010006046314290000
Version ..........: 2.1
Manufacturer .....: Yubico
Serial number ....: 04631429
Name of cardholder: sm sm
Language prefs ...: en
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: sm
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: 54D4 E469 7056 B390 AE72 CAA1 A507 3320 7876 0302
created ....: 2017-10-11 13:16:52
Encryption key....: ADA3 2D7F 8D66 4F34 C04A 457C DFEB E3E4 A8F1 8611
created ....: 2017-10-11 11:14:18
Authentication key: 18B9 7AB4 0723 46F4 C23A 3DD7 E5C0 6A93 049E F6A8
created ....: 2017-10-11 11:14:18
General key info..: [none]
gpg/card> admin
Admin commands are allowed
gpg/card> generate
Make off-card backup of encryption key? (Y/n) n
gpg: Note: keys are already stored on the card!
Replace existing keys? (y/N) y
What keysize do you want for the Signature key? (4096)
What keysize do you want for the Encryption key? (4096)
What keysize do you want for the Authentication key? (4096)
Key is valid for? (0) 0
Is this correct? (y/N) y
Real name: john doe
Email address: john.doe#foobar.com
Comment:
You selected this USER-ID:
"john doe <<john.doe#foobar.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
gpg: /home/xxx/.gnupg/trustdb.gpg: trustdb created
gpg: key 6825CB0EBDA94110 marked as ultimately trusted
gpg: directory '/home/xxx/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/xxx/.gnupg/openpgp-revocs.d/6858F119E93FB74BB561DE556825CB0EBDA94110.rev'
public and secret key created and signed.
gpg/card> list
Reader ...........: 1050:0404:X:0
Application ID ...: D2760001240102010006046314290000
Version ..........: 2.1
Manufacturer .....: Yubico
Serial number ....: 04631429
Name of cardholder: sm sm
Language prefs ...: en
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: sm
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 4
Signature key ....: 6858 F119 E93F B74B B561 DE55 6825 CB0E BDA9 4110
created ....: 2017-10-11 13:18:11
Encryption key....: BE05 7FDF 9ACD 05F0 B75A 570F 4711 4B69 A622 C1DC
created ....: 2017-10-11 13:18:11
Authentication key: 7275 2C47 B1EF BFB5 1E6D 0E65 31C7 7DBE 2D22 7E32
created ....: 2017-10-11 13:18:11
General key info..: pub rsa4096/6825CB0EBDA94110 2017-10-11 john doe <<john.doe#foobar.com>
sec> rsa4096/6825CB0EBDA94110 created: 2017-10-11 expires: never
card-no: 0006 04631429
ssb> rsa4096/31C77DBE2D227E32 created: 2017-10-11 expires: never
card-no: 0006 04631429
ssb> rsa4096/47114B69A622C1DC created: 2017-10-11 expires: never
card-no: 0006 04631429
gpg/card> quit
$ rm -rf .gnupg/
$ gpg --card-status
gpg: directory '/home/smalatho/.gnupg' created
gpg: new configuration file '/home/smalatho/.gnupg/dirmngr.conf' created
gpg: new configuration file '/home/smalatho/.gnupg/gpg.conf' created
gpg: keybox '/home/smalatho/.gnupg/pubring.kbx' created
Reader ...........: 1050:0404:X:0
Application ID ...: D2760001240102010006046314290000
Version ..........: 2.1
Manufacturer .....: Yubico
Serial number ....: 04631429
Name of cardholder: sm sm
Language prefs ...: en
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: sm
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 4
Signature key ....: 6858 F119 E93F B74B B561 DE55 6825 CB0E BDA9 4110
created ....: 2017-10-11 13:18:11
Encryption key....: BE05 7FDF 9ACD 05F0 B75A 570F 4711 4B69 A622 C1DC
created ....: 2017-10-11 13:18:11
Authentication key: 7275 2C47 B1EF BFB5 1E6D 0E65 31C7 7DBE 2D22 7E32
created ....: 2017-10-11 13:18:11
General key info..: [none]
OpenPGP smart cards do not store enough information to reconstruct a full OpenPGP public key. You must import the public key separately -- sharing it on a key servers is one solution, but you can also gpg --export the key and later gpg --import it again for testing.
It requires the user to manually export the public key before deleting GNUPGHOME directory and then re-importing the public key in the smart card.
$ gpg --armor --export j.doe#example.com > public.asc
$ rm -rf ~/.gnupg
$ gpg --import public.asc
According to the maintainer of GnuPG, it is technically possible to reconstruct the public key using only information from the card but it isn't easy:
However, if you really lost the public key and you need it back, it is possible to re-create the public key with the same fingerprint. There is no code for this, you need to hack the source.
What you need is the creation timestamp and the public key parameters
from the card. You can gather this information using
$ gpg-connect-agent
> scd learn --force
S SERIALNO D276000124010101000100xxxxxxxxxx 0
S APPTYPE OPENPGP
[...]
S KEY-TIME 1 1136130759
S KEY-TIME 2 1136132140
S KEY-TIME 3 1136131786
[...]
OK
> /decode
> /hex
> scd readkey OPENPGP.1
D[0000] 28 31 30 3A 70 75 62 6C 69 63 2D 6B 65 79 28 33 (10:public-key(3
D[0010] 3A 72 73 61 28 31 3A 6E 31 32 39 3A 00 D0 99 19 :rsa(1:n129:....
[...]
OK
Take the creation time from the KEY-TIME lines. I used /decode and /hex above only for readability. You should use
> /datafile out
> scd readkey OPENPGP.1
OK
> /bye
instead which writes the s-expression with the public key to the file out. The Libgcrypt functions take those s-expressions as arguments. Now you need to feed it to gpg to create the public key part and the self-signatures.