Any code using Mail::IMAPClient is having this error. To verify I have used the below example from the topic: How do I authenticate into Gmail using Perl?
#!/usr/bin/env perl -w
use strict; use warnings;
use Mail::IMAPClient;
# Connect to IMAP server
my $client = Mail::IMAPClient->new(
Server => 'imap.gmail.com',
User => $user,
Password => $pass,
Port => 993,
Ssl => 1,
)
or die "Cannot connect through IMAPClient: $#";
# List folders on remote server (see if all is ok)
if ( $client->IsAuthenticated() ) {
print "Folders:\n";
print "- ", $_, "\n" for #{ $client->folders() };
};
# Say so long
$client->logout();
Now, I have gone through questions similar to this but have never seen such a strange error like "Network Unreachable". There is no actual network problem, ping works fine. I have IO::Socket::SSL, Net::SSLeay installed.
$ echo -n | openssl s_client -connect imap.gmail.com:993
CONNECTED(00000003)
depth=2 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = imap.gmail.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
i:/C=US/O=Google Inc/CN=Google Internet Authority
1 s:/C=US/O=Google Inc/CN=Google Internet Authority
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDWzCCAsSgAwIBAgIKFefcnAADAAA7OzANBgkqhkiG9w0BAQUFADBGMQswCQYD
VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu
dGVybmV0IEF1dGhvcml0eTAeFw0xMTExMTgwMjAxMjRaFw0xMjExMTgwMjExMjRa
MGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N
b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRcwFQYDVQQDEw5pbWFw
LmdtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAmv2pvvhXOyOA
Uq053VLGMAErgk2NcDzxWNB5PWwXHzkcFuZOa0q1YUlff6LaJurq5UctkOO+3mt1
L+/wcZiEzxTdfOclyJcY/qBsjz8qgG+4Kx3/dVlTYz2geUyxvGNibNQfuXpoI1M5
iUQ/FSaFIazXZ01tpb+mgCOtwzENMk8CAwEAAaOCASwwggEoMB0GA1UdDgQWBBRd
l+HsAH5IwfNuc25lLuryGEaXwzAfBgNVHSMEGDAWgBS/wDDr9UMRPme6npH7/Gra
42sSJDBbBgNVHR8EVDBSMFCgTqBMhkpodHRwOi8vd3d3LmdzdGF0aWMuY29tL0dv
b2dsZUludGVybmV0QXV0aG9yaXR5L0dvb2dsZUludGVybmV0QXV0aG9yaXR5LmNy
bDBmBggrBgEFBQcBAQRaMFgwVgYIKwYBBQUHMAKGSmh0dHA6Ly93d3cuZ3N0YXRp
Yy5jb20vR29vZ2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRo
b3JpdHkuY3J0MCEGCSsGAQQBgjcUAgQUHhIAVwBlAGIAUwBlAHIAdgBlAHIwDQYJ
KoZIhvcNAQEFBQADgYEAa6JYZBInXMfojI4bXLusfDlzZ6gnGtHxOO8hUZbDAwcL
t2/4uDDj8sroVrTWXMqURzk1lCsXlGPFhaKdnsMrmcgC01THAKPFrrQnQc/BM5H/
kr5ZAyJKHyu4dNnL3NNjig+22fp8slaLo25C95YQT5LiBL2qnAzLs4nWBzqih74=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=imap.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority
---
No client certificate CA names sent
---
SSL handshake has read 1850 bytes and written 299 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: D98F3659858A0F39D32F1B5D96F756DE6E093E849A6AE0066C391BE2881B9A69
Session-ID-ctx:
Master-Key: 8D4BE4DFEB7F3218A501FE9240E0B51CC987B99EE0DDBA5EC13E9A10137B63508692DA684DA25E8B2839906F0F7ADDD5
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 6e 26 64 bb c3 97 30 9c-32 6f c5 38 d6 db 23 54 n&d...0.2o.8..#T
0010 - 65 43 b8 01 4e 46 5b b3-81 7e 26 6b 3a 36 2b 62 eC..NF[..~&k:6+b
0020 - 03 96 44 de 3d b0 81 be-18 b0 14 a1 09 99 28 73 ..D.=.........(s
0030 - 2d 5a 87 6c b9 26 64 94-af f2 5e f1 f4 10 ba ff -Z.l.&d...^.....
0040 - 68 a0 6a 31 d6 10 f8 88-61 63 5a 58 0b 1d d0 98 h.j1....acZX....
0050 - 81 ed f7 45 11 1d 4a 22-23 2f 44 0c 62 b4 18 e9 ...E..J"#/D.b...
0060 - e7 4a 57 10 f1 3c a0 d6-ee 46 98 5d df e9 a5 52 .JW..<...F.]...R
0070 - a6 75 da a6 25 89 87 f0-b0 ec 60 0d c0 19 0e 6f .u..%.....`....o
0080 - 23 53 a2 f2 18 e8 8d 51-28 e7 f2 d3 52 8a 02 f4 #S.....Q(...R...
0090 - 32 aa 82 db 2...
Start Time: 1342180574
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
this could be an ipv6 error. Gmail enabled ipv6 access recently. Can you try putting this before the 'use Mail::IMAPClient;' line:
use IO::Socket::SSL 'inet4';
Related
I am having a problem with Google's SMTP servers. They reject my SMTP server's IP for no valid reason. My server complies with all the necessary rules to deliver the message but Google rejects it by IP without giving me details and I cannot find support either. I have written to postmaster#gmail.com but got no response. My server sends notifications to the users of the system, it does not do SPAM and apparently everything is correct. I don't see a valid reason for this crash, and I can't find a way to fix it. I would like to know if the same thing happened to someone and how they could solve it. Next I copy the console with the delivery attempt and additionally some DNS checks that show that apparently there is no problem on my server:
root#venabili:~# hostname -f
venabili.tecnologica.com.ar
root#venabili:~# id
uid=0(root) gid=0(root) grupos=0(root)
root#venabili:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 200.69.236.179 netmask 255.255.255.0 broadcast 200.69.236.255
inet6 fe80::f816:3eff:fe27:b8e1 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:27:b8:e1 txqueuelen 1000 (Ethernet)
RX packets 302342269 bytes 32703331063 (30.4 GiB)
RX errors 0 dropped 17 overruns 0 frame 0
TX packets 75025298 bytes 12670842456 (11.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root#venabili:~# nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> set type=mx
> tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
tecnologica.com.ar mail exchanger = 10 venabili.tecnologica.com.ar.
Authoritative answers can be found from:
> set type=a
> venabili.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: venabili.tecnologica.com.ar
Address: 200.69.236.179
> set type=aaaa
> venabili.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: venabili.tecnologica.com.ar
Address: fe80::f816:3eff:fe27:b8e1
> set type=ptr
> 200.69.236.179
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
179.236.69.200.in-addr.arpa name = venabili.tecnologica.com.ar.
Authoritative answers can be found from:
> set type=txt
> tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
tecnologica.com.ar text = "v=spf1 a mx ip4:200.69.236.179 ip6:fe80::f816:3eff:fe27:b8e1 ~all"
Authoritative answers can be found from:
> set type=txt
> default._domainkey.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
default._domainkey.tecnologica.com.ar text = "v=DKIM1; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz+GrX8vxp9W51ehJuixhL5AbjmCgcN2h7KqMiLI8LMUfmpWPP1GIhxlWCieFUVMOAQGlQrImuFE3kk/qLOgyumzUTRBwxlNX+7tix7dlBclXAWq8SjB9SbbAcPKkTBAq0pvXvp4l4qTCFnfVXAs1g/lCywlJrbfAFVVXWdN44ElFz+bD4YRYsXSmz//L1uFU7YE" "zkFUvbMtwBOL1xRvjAFXH4xQ7/vkHX6+OIxnm47vO/a2CqFVXok0FhAj44BmlBT+Py0x0SP8jsm+xhnLc238ZIsGylTwCb0Zbl3DR9bKGBy9FqXoUyRIzWKEkAtwaKq7qeBO3oRT4kQOKEOog2QIDAQAB"
Authoritative answers can be found from:
> _dmarc.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
_dmarc.tecnologica.com.ar text = "v=DMARC1; p=reject; rua=mailto:postmaster#tecnologica.com.ar; ruf=mailto:postmaster#tecnologica.com.ar"
Authoritative answers can be found from:
> _smtp._tls.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
_smtp._tls.tecnologica.com.ar text = "v=TLSRPTv1; rua=mailto:postmaster#tecnologica.com.ar"
Authoritative answers can be found from:
> _mta-sts.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
_mta-sts.tecnologica.com.ar text = "v=STSv1; id=20200918192500"
Authoritative answers can be found from:
> set type=cname
> mta-sts.tecnologica.com.ar
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
mta-sts.tecnologica.com.ar canonical name = venabili.tecnologica.com.ar.
Authoritative answers can be found from:
> exit
root#venabili:~# openssl s_client -connect mta-sts.tecnologica.com.ar:443
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mta-sts.tecnologica.com.ar
verify return:1
---
Certificate chain
0 s:CN = mta-sts.tecnologica.com.ar
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFbTCCBFWgAwIBAgISBC7Vr1sblDEJHYgxBtfro6xcMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA5MTgyMzM4MjdaFw0y
MDEyMTcyMzM4MjdaMCUxIzAhBgNVBAMTGm10YS1zdHMudGVjbm9sb2dpY2EuY29t
LmFyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5glA7vEmuS0EzKhn
w9IfLPHHertYYOYx54t/2zr8G1pSmkCjrOlfV+YHwIuWeehxDUz/ezy1JXyK11kd
raDd71MoBd9mV12fjITO99oDpkYu9g09TxJ9rpIEkU8LRGkgjfDGBBtf5X5Za+Ah
gWbJ4JudVoykVZ00riQsZzbfJ8FNZcwEgErWCZCBL45tR7tfeFlXTJGFhyszqQN+
r4gS3C/JpsObIMaoqmkJrO5YUGcfGvqDOG3INthp2L9/t743OfYUGTqRFu09Rq5S
xwEYxR8GksaLwzMWOIRelMP4W5F9ce7hhdxU68cK4j9rHXaaeNXLySeMs7K9C2vt
p1nnowIDAQABo4ICcDCCAmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQ1A7mXXvtb
eS6ZYRtw4EA7WhJ3/zAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBv
BggrBgEFBQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5s
ZXRzZW5jcnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5s
ZXRzZW5jcnlwdC5vcmcvMCUGA1UdEQQeMByCGm10YS1zdHMudGVjbm9sb2dpY2Eu
Y29tLmFyMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYI
KwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBQYKKwYBBAHW
eQIEAgSB9gSB8wDxAHcA5xLysDd+GmL7jskMYYTx6ns3y1YdESZb8+DzS/JBVG4A
AAF0o8xFcQAABAMASDBGAiEAlc3Q8FEkd5ZUayxVfeorQv9+Jt1OSgOOP+jqVw5K
sskCIQCE0Hx7YDWcJ9o4Cck50WP7UtA/qRgmfn1fVIHyEZMftwB2AAe3XBvlfWj/
8bDGHSMVx7rmV3xXlLdq7rxhOhpp06IcAAABdKPMRZcAAAQDAEcwRQIgBVUd9xxC
DVX/kr0+308ra9YOqJC/yvBJnktxWg6YUVMCIQCR14/ouxc+Ydm4tePVBjBnmpRq
QzQEDYrd+4R7JjpiCjANBgkqhkiG9w0BAQsFAAOCAQEAlCnRwvP7wNRHTzB5N9/N
2cBPuVxKbvf1rHwusXYzQBVlyM6grEvjTgd5V/C+we1ueDUp991tP3z5AAksIGWM
/ssDlK0VSxv9PIzC1LxDK39Sl+P8xkuGj0zSDYg321sFjFyZLashP+xFYyzx3QdD
9h65J0uB/BigWOIN9sK1vLVhIB4yqV190vucyMamJBZ1dvSaYCi52dCgEEsAxM3v
LksETYgpSqB4+6zB2ae3/FN2/m3vyWCdFv1fL19hIidKjwIYhIKVOLKTQCYvCd+p
srhlTtnRf8i+P8Dni9xKmKSFwSGc8L+AS0AfTh6M/+IEPOO2zJsp1R/PBWgiy42v
fw==
-----END CERTIFICATE-----
subject=CN = mta-sts.tecnologica.com.ar
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3203 bytes and written 403 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
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-CHACHA20-POLY1305
Session-ID: 38FDD25BCB4C28F5364CA3418C05D13F279E62882E594190276850599BB67EAB
Session-ID-ctx:
Master-Key: 41AEF29EC1545AAE8C53958032EFF464E237232D8AA9D22CF9513297DFFBA40645226685FE58FEC782DA20CDFFEB5EDB
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 5f 78 fa 6f 3a 54 9c c2-f0 8e b2 b7 70 13 05 d4 _x.o:T......p...
0010 - 4b 39 84 62 c7 cb 96 f8-89 5c 27 09 6c 2b aa ad K9.b.....\'.l+..
0020 - 52 22 36 d6 a3 0b 8b 5e-ed 4b 78 f5 49 61 47 69 R"6....^.Kx.IaGi
0030 - c9 e7 41 88 c2 e6 29 86-b5 52 a9 8f 56 3f 79 3e ..A...)..R..V?y>
0040 - 14 bd b5 24 ca c5 f7 a4-ab b9 f9 26 dc 1c 71 7a ...$.......&..qz
0050 - ab 5a a2 a9 76 df 61 70-a5 91 5f 69 36 bc 64 69 .Z..v.ap.._i6.di
0060 - 02 b5 4b ba 79 e0 c9 a7-3b e2 a6 30 9b 2b 34 33 ..K.y...;..0.+43
0070 - 02 af 1e 3c 82 90 bc ca-32 b3 57 5b e0 b6 33 b0 ...<....2.W[..3.
0080 - a6 4c dc a8 c9 01 29 cf-98 ba 7c 40 3a ae 4b 04 .L....)...|#:.K.
0090 - 95 66 2f 96 b2 b9 5b f1-b0 f2 b0 6c e4 61 6f d0 .f/...[....l.ao.
00a0 - 98 a2 67 06 c9 22 ef a3-f5 ec 24 ac a2 b1 5f 4e ..g.."....$..._N
Start Time: 1600571394
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
GET /.well-known/mta-sts.txt HTTP/1.1
Host: venabili.tecnologica.com.ar
HTTP/1.1 200 OK
Server: nginx/1.14.2
Date: Sun, 20 Sep 2020 03:10:22 GMT
Content-Type: text/plain
Content-Length: 77
Last-Modified: Sat, 19 Sep 2020 14:07:46 GMT
Connection: keep-alive
ETag: "5f6610b2-4d"
Accept-Ranges: bytes
version: STSv1
mode: testing
mx: venabili.tecnologica.com.ar
max_age: 604800
^C
root#venabili:~# openssl s_client -starttls smtp -connect venabili.tecnologica.com.ar:587 -crlf -ign_eof
CONNECTED(00000004)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = venabili.tecnologica.com.ar
verify return:1
---
Certificate chain
0 s:CN = venabili.tecnologica.com.ar
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFbzCCBFegAwIBAgISBAyLUnN1zyR0tAMF7k1G3023MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA5MTgyMjMxMjZaFw0y
MDEyMTcyMjMxMjZaMCYxJDAiBgNVBAMTG3ZlbmFiaWxpLnRlY25vbG9naWNhLmNv
bS5hcjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL/svQH9FsoQZyGh
krGZLrN3GAzwuAV2IEsYdAixVrVXGPPjA4oTxQDWncBPVh8x6nMstJqq4xP19aBr
pw5P2rcsMvLT9RJ14wGuNzzDcx9uOmR709ZrPpPzZJ4JJnZxQP5dE2jJMrPQ7tnI
3AudscEaAMW8qBLj91jPDiv4LbRHL4xU+w46yZbB6szgb4u567SSKFaVlRQ8tmCt
msIkYdA5mP5/1Z0QN6PgtAzCWECEkn/eRpuTUHliMjgCocwQ3RYkofGrNQ1a4H7F
RgdaQzjCjQ7JdT/pZTYWrejr3alMsFAukRfIH/FMI5v8ojaxzlQOhz46WJiw3qNH
rmjb+G0CAwEAAaOCAnEwggJtMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr
BgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQU91GfsO41
iPZN1SROqwqnCPSN9yIwHwYDVR0jBBgwFoAUqEpqYwR93brm0Tm3pkVl7/Oo7KEw
bwYIKwYBBQUHAQEEYzBhMC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcC5pbnQteDMu
bGV0c2VuY3J5cHQub3JnMC8GCCsGAQUFBzAChiNodHRwOi8vY2VydC5pbnQteDMu
bGV0c2VuY3J5cHQub3JnLzAmBgNVHREEHzAdght2ZW5hYmlsaS50ZWNub2xvZ2lj
YS5jb20uYXIwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMBAQEwKDAm
BggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEFBgorBgEE
AdZ5AgQCBIH2BIHzAPEAdwDnEvKwN34aYvuOyQxhhPHqezfLVh0RJlvz4PNL8kFU
bgAAAXSjjusOAAAEAwBIMEYCIQDOwhtVW/tkJzexdCpcX2gLXX7axA8Fw4bDURrr
tu/ecQIhAKpdzqz+iWGw9I7pkKfYNjyyLdWojRlT+IYQfR7qxQc4AHYAB7dcG+V9
aP/xsMYdIxXHuuZXfFeUt2ruvGE6GmnTohwAAAF0o47rMwAABAMARzBFAiBUUOSO
S+8ueu2ACk+862qxbAsXylwZAfHhg/7HmEeEQQIhAKq3jqMMSIjTo47t2JXrU58d
PP6E3NwNHOgGCNje4R/nMA0GCSqGSIb3DQEBCwUAA4IBAQAua/T4drS/7xpNmGDV
Xp2iFhSaVsbWeHh5+40POEAy9NvaZ8O4CeNjV3NeV84QI2Jh1PjehebM72K85rCT
7jEOqaJY5vmKrLBVji6MsgryyGLm4Y368nMR3JrXDLUkATgart+jLdsxLbaRsI1t
Gf+BLc6TYb4roGiI7TTjEQDAy2SOGqfOWbAEdVKIEr9P3IBrlOSOl2o8gd97PXQ/
vEmklVM/5zr5l5paInHOidBL8y8qVk2s9AkaQNAS2QTX5+iFl9D1u8z5mz49eKPb
sb9GSFVTm/qe0KHl02qga4/1ANRoNCuKoaE5xxhqyboJwy58qp7opbzipqxbQI0T
N8e/
-----END CERTIFICATE-----
subject=CN = venabili.tecnologica.com.ar
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3389 bytes and written 432 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: D8A0F5C48FBFE47FAEF6482AC696CBCAB01EB030F683053A41539DCD5B91E593
Session-ID-ctx:
Resumption PSK: 3CACF3832764ACCF8A00FFDAFA9A8771E62C04FCDF1429A85EB2A3AC0F39733F642045E4602CE73F62AEC75745B51392
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 30 00 51 89 4c df 15 62-da 50 55 37 92 60 65 f2 0.Q.L..b.PU7.`e.
0010 - 05 72 39 3d fb 1e 8a 05-2f 95 6b f0 cd 33 29 b0 .r9=..../.k..3).
0020 - b7 38 89 4f 2f 32 91 66-f7 59 2f 80 43 fc 81 f7 .8.O/2.f.Y/.C...
0030 - c6 53 68 3d d8 69 0d 10-6c 4c 62 9c 81 d9 ec 60 .Sh=.i..lLb....`
0040 - 9f ef a0 95 46 d3 e0 10-29 09 20 ab 48 3b 07 34 ....F...). .H;.4
0050 - 82 d3 0e 39 3d 11 18 e8-9e 44 b7 69 b9 d0 45 2e ...9=....D.i..E.
0060 - 97 4f da 69 aa 89 27 2c-e5 9c 63 39 4b f8 3f 54 .O.i..',..c9K.?T
0070 - 23 1a db 73 ac 7e 78 20-76 f5 67 b9 8f e1 c3 34 #..s.~x v.g....4
0080 - d7 f0 b5 0b 0d c7 dc 80-f6 40 0c 20 3f 8d 16 b7 .........#. ?...
0090 - 3a c2 e2 a9 c1 b6 fd 84-65 7f a5 1c 16 81 60 5a :.......e.....`Z
00a0 - 53 12 3a bf d0 4a 0c 0e-a2 3b 57 ce ad 63 89 e6 S.:..J...;W..c..
00b0 - a7 58 ea 21 f9 2e 04 00-ff 6f a7 40 9d 2c bf 39 .X.!.....o.#.,.9
00c0 - 8d d9 19 c9 e1 05 a6 19-a4 60 06 75 8d 3e 95 89 .........`.u.>..
Start Time: 1600567929
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
ehlo venabili.tecnologica.com.ar
250-venabili.tecnologica.com.ar
250-PIPELINING
250-SIZE
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
auth login
334 VXNlcm5hbWU6
bm8tcmVzcG9uZGVyQHRlY25vbG9naWNhLmNvbS5hcg==
334 UGFzc3dvcmQ6
!!!
235 2.7.0 Authentication successful
mail from: no-responder#tecnologica.com.ar
250 2.1.0 Ok
rcpt to: jmouriz#gmail.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
from: root <no-responder#tecnologica.com.ar>
to: Juan Manuel Mouriz <jmouriz#gmail.com>
subject: Mensaje de prueba
Hola, este es un mensaje de prueba
.
250 2.0.0 Ok: queued as 5E50844853
quit
221 2.0.0 Bye
closed
root#venabili:~# grep 5E50844853 /var/log/mail.log
Sep 19 23:18:54 venabili postfix/submission/smtpd[7994]: 5E50844853: client=venabili.tecnologica.com.ar[200.69.236.179], sasl_method=login, sasl_username=no-responder#tecnologica.com.ar
Sep 19 23:20:35 venabili postfix/cleanup[8543]: 5E50844853: message-id=<20200920021854.5E50844853#venabili.tecnologica.com.ar>
Sep 19 23:20:35 venabili postfix/qmgr[5677]: 5E50844853: from=<no-responder#tecnologica.com.ar>, size=554, nrcpt=1 (queue active)
Sep 19 23:20:35 venabili postfix/cleanup[8543]: 6F3BE4485D: message-id=<20200920021854.5E50844853#venabili.tecnologica.com.ar>
Sep 19 23:20:35 venabili amavis[26666]: (26666-19) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL [200.69.236.179]:55833 [200.69.236.179] <no-responder#tecnologica.com.ar> -> <jmouriz#gmail.com>, Queue-ID: 5E50844853, Message-ID: <20200920021854.5E50844853#venabili.tecnologica.com.ar>, mail_id: bcEyyqxUQvNK, Hits: -1, size: 554, queued_as: 6F3BE4485D, dkim_new=default:tecnologica.com.ar, 329 ms
Sep 19 23:20:35 venabili postfix/smtp[8676]: 5E50844853: to=<jmouriz#gmail.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=115, delays=115/0.02/0.01/0.32, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 6F3BE4485D)
Sep 19 23:20:35 venabili postfix/qmgr[5677]: 5E50844853: removed
root#venabili:~# grep 6F3BE4485D /var/log/mail.log
Sep 19 23:20:35 venabili postfix/smtpd[8679]: 6F3BE4485D: client=localhost[127.0.0.1]
Sep 19 23:20:35 venabili postfix/cleanup[8543]: 6F3BE4485D: message-id=<20200920021854.5E50844853#venabili.tecnologica.com.ar>
Sep 19 23:20:35 venabili postfix/qmgr[5677]: 6F3BE4485D: from=<no-responder#tecnologica.com.ar>, size=1625, nrcpt=1 (queue active)
Sep 19 23:20:35 venabili amavis[26666]: (26666-19) Passed CLEAN {RelayedOutbound}, ORIGINATING LOCAL [200.69.236.179]:55833 [200.69.236.179] <no-responder#tecnologica.com.ar> -> <jmouriz#gmail.com>, Queue-ID: 5E50844853, Message-ID: <20200920021854.5E50844853#venabili.tecnologica.com.ar>, mail_id: bcEyyqxUQvNK, Hits: -1, size: 554, queued_as: 6F3BE4485D, dkim_new=default:tecnologica.com.ar, 329 ms
Sep 19 23:20:35 venabili postfix/smtp[8676]: 5E50844853: to=<jmouriz#gmail.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=115, delays=115/0.02/0.01/0.32, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10027): 250 2.0.0 Ok: queued as 6F3BE4485D)
Sep 19 23:20:37 venabili postfix/smtp[8680]: 6F3BE4485D: to=<jmouriz#gmail.com>, relay=gmail-smtp-in.l.google.com[172.217.192.26]:25, delay=1.7, delays=0.02/0.02/0.88/0.8, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[172.217.192.26] said: 550-5.7.1 [200.69.236.179] The IP you're using to send mail is not authorized to 550-5.7.1 send email directly to our servers. Please use the SMTP relay at your 550-5.7.1 service provider instead. Learn more at 550 5.7.1 https://support.google.com/mail/?p=NotAuthorizedError a44si4686321qtk.87 - gsmtp (in reply to end of DATA command))
Sep 19 23:20:37 venabili postfix/bounce[8681]: 6F3BE4485D: sender non-delivery notification: 32EF64485E
Sep 19 23:20:37 venabili postfix/qmgr[5677]: 6F3BE4485D: removed
root#venabili:~#
The domain in question is tecnologica.com.ar and I leave a link to some verifications where it is seen that the RR SPF, DKIM, DMARC, _SMTP._TLS, _MTA-STS, MTA-STS, CAA and PTR are correct and it is not a open relay:
https://mxtoolbox.com/domain/tecnologica.com.ar
The certificates are signed by Let's Encrypt. The host name matches the certificate. The classes are correct. And finally, I do not SPAM. I would greatly appreciate a help because at this point I am completely disoriented and can't find what else to do.
I am not looking for a solution but rather where I can find it.
Thank you very much for your help
Additional info
This is a report domain for DMARC:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support#google.com</email>
<extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>7762784093316082866</report_id>
<date_range>
<begin>1603756800</begin>
<end>1603843199</end>
</date_range>
</report_metadata>
<policy_published>
<domain>tecnologica.com.ar</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>200.69.236.179</source_ip>
<count>2</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>tecnologica.com.ar</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>tecnologica.com.ar</domain>
<result>pass</result>
<selector>default</selector>
</dkim>
<spf>
<domain>tecnologica.com.ar</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
And this is a report domain for TLS:
{"organization-name":"Google Inc.","date-range":{"start-datetime":"2020-10-26T00:00:00Z","end-datetime":"2020-10-26T23:59:59Z"},"contact-info":"smtp-tls-reporting#google.com","report-id":"2020-10-26T00:00:00Z_tecnologica.com.ar","policies":[{"policy":{"policy-type":"sts","policy-string":["version: STSv1\r","mode: testing\r","mx: venabili.tecnologica.com.ar\r","max_age: 604800\r","\r"],"policy-domain":"tecnologica.com.ar"},"summary":{"total-successful-session-count":1,"total-failure-session-count":0}}]}
I am doing a tutorial on Mutual SSL authentication using tomcat. I tried google and stackoverflow for the answer but I haven't been lucky so far. I have done the following steps
1. Generated a self signed Certificate using the command as...
keytool -genkey -v -alias tomcat -keyalg RSA -validity 3650 -keystore D:\server.keystore -dname "CN=KeshavServer,OU=AppDev,O=Netambit,L=Noida,S=UP,C=IN" -storepass server123 -keypass server123
Result(DOS Output):
Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 3,650 days for: CN=KeshavServer, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
New certificate (self-signed):
[
[
Version: V3
Subject: CN=KeshavServer, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 169745031109692228700332160907879660712549791227819060217679327134557
60724387920644418620368961814809125561438164385172820012631533276651192871536066
44484789458740611952365817466495640787815691991239210085729312562284526930712191
68874744017392521167643053301439564836240073082909781032758910760996909343586608
99178037089977353808963798076122662239868847716719923568980681140353282369676681
53737103284233931190726847482006084262000642602659963850552605206369455374224663
42718874198088754429094645464054866254482989193982685337964154043630072713972109
68332098433075932439269617793403644275259520886009675985568022246951
public exponent: 65537
Validity: [From: Mon Aug 12 12:16:13 IST 2013,
To: Thu Aug 10 12:16:13 IST 2023]
Issuer: CN=KeshavServer, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
SerialNumber: [ 713ab315]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D6 0E 1F 23 B2 11 92 D2 19 7B C9 AA 19 EF 82 EB ...#............
0010: A6 0C 35 57 ..5W
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 4C 36 84 CD FE 2C 11 4B 88 C1 AE 3A 7A 6A A1 C4 L6...,.K...:zj..
0010: 2C 6E F5 73 33 64 57 06 04 7F AC 1B D6 CA BF E0 ,n.s3dW.........
0020: D2 88 09 A9 B8 4D 70 EE 73 6E 02 45 33 83 42 1E .....Mp.sn.E3.B.
0030: C4 8E 67 F3 51 D7 9C 53 08 CD C7 EA 4B BC 27 0D ..g.Q..S....K.'.
0040: 17 36 9B 12 4A F7 F7 23 0E C2 51 0A 18 06 B5 80 .6..J..#..Q.....
0050: 1C 44 17 0D 99 14 6E 27 40 30 56 DF 31 D9 CC 15 .D....n'#0V.1...
0060: 46 7C 72 C2 54 CE 2E 2B 41 94 19 54 9B 3A F7 85 F.r.T..+A..T.:..
0070: 96 CE 5F 80 C5 A5 02 AE 09 17 A5 C3 E4 A6 BB 63 .._............c
0080: A3 EF 99 4F BC A4 FF 4F 2B BD 46 E5 BE 57 C7 BD ...O...O+.F..W..
0090: 85 54 F9 B1 5F 01 18 07 9F DD 02 99 91 B3 35 FB .T.._.........5.
00A0: 62 74 2A 0A 37 8A 9B 0D E8 BF B4 24 CE 24 12 8A bt*.7......$.$..
00B0: 22 68 39 90 BD 02 24 A4 E9 9B 52 E1 AA 76 1D 16 "h9...$...R..v..
00C0: 91 2A 60 49 D3 F6 91 0A 01 E4 98 1B BB EB B7 E5 .*`I............
00D0: E3 DF 39 B8 73 02 C3 1D EA 95 D1 95 A7 27 53 FC ..9.s........'S.
00E0: 28 2B 21 50 90 BF 48 9A 25 92 28 D8 EC FE 82 60 (+!P..H.%.(....`
00F0: B9 21 28 B3 1A 37 B6 79 17 8B FF 4C 0B C1 6D 0C .!(..7.y...L..m.
]
[Storing D:\server.keystore]
2. Generated the developer key by using the command as...
keytool -genkey -v -alias developerKey -keyalg RSA -storetype PKCS12 -keystore dev.p12 -dname "CN=KeshavClient,OU=AppDev,O=Netambit,L=Noida,S=UP,C=IN" -storepass dev123 -keypass dev123
Result(DOS Output):
Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) wi
th a validity of 90 days
for: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
New certificate (self-signed):
[
[
Version: V3
Subject: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 257861330490904259854513552509935970316490717846991127699603148980652
01114722960469328519589253139525292368465436006354129813882061510118729695295380
60706390500779076802188937858019079525575493711793923541823056735274180328061957
20693618061100873813154701306998418961615717804323475393466678818363454317730604
32071710089666113885067366725913386597296681138020057906688646996872449490785655
01898351843152376966821908896570275550705585694195185294854938453556896208850780
54361881798687601045808741784626686357148783050499722574071065943861302398542177
91929018282855348848062666985932392623629290470810910913665654471519
public exponent: 65537
Validity: [From: Mon Aug 12 12:16:26 IST 2013,
To: Sun Nov 10 12:16:26 IST 2013]
Issuer: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
SerialNumber: [ 503c03cf]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AD 4A E3 0E 3D E9 DB B0 8E DF 8F 66 34 28 AE AF .J..=......f4(..
0010: 34 63 F2 4C 4c.L
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 91 79 CF CC 0F FD CA BB 2A 60 5E 87 8F 2F 6D B6 .y......*`^../m.
0010: DD 71 05 6A B1 21 DB B0 B0 0F D7 3E 7A DB 12 84 .q.j.!.....>z...
0020: 3A C0 63 1B C1 FE FD C5 60 27 E3 2E 14 A0 38 2C :.c.....`'....8,
0030: EE 82 8C 6E 13 05 8A BC 24 2F A1 4F 5C 25 24 10 ...n....$/.O\%$.
0040: EC 5A D1 E3 23 AC 51 BA D4 33 6C AF AF A2 68 2F .Z..#.Q..3l...h/
0050: 29 4F 33 F9 0A 56 C1 83 0C 07 30 14 40 A2 CF 17 )O3..V....0.#...
0060: B1 A1 18 AD 51 76 EA 8E D6 6E 50 4E 7A 7C F5 89 ....Qv...nPNz...
0070: B1 73 F4 05 D2 E9 1B 94 48 2F 65 30 33 F4 1B 28 .s......H/e03..(
0080: AA 36 4C 11 52 C5 2A 9D 4A 11 6D FA 9B C6 09 37 .6L.R.*.J.m....7
0090: A1 CC AC A3 67 B1 60 E6 65 F1 0C 98 0E 5E C0 89 ....g.`.e....^..
00A0: BD 54 98 81 51 DB 6C 53 A5 8C AD 05 57 60 46 20 .T..Q.lS....W`F
00B0: 5E 60 74 58 F8 88 2A 46 F6 F5 5A D3 20 FC 9E FA ^`tX..*F..Z. ...
00C0: 8D 14 A8 72 99 F5 FF 9E 0B 5B F9 68 77 30 75 93 ...r.....[.hw0u.
00D0: 3E 7A 16 38 55 11 30 D6 A1 39 97 97 DB 86 B8 9E >z.8U.0..9......
00E0: 3F 08 84 93 A3 A7 E0 4F 6D 07 A2 E6 F9 09 E8 3B ?......Om......;
00F0: 6C 86 F2 26 F6 20 04 D9 92 66 DC 3B 69 FA 75 30 l..&. ...f.;i.u0
]
[Storing dev.p12]
3 Exported and saved the certificate in dev.cer
keytool -export -alias developerKey -keystore dev.p12 -storetype PKCS12 -storepass dev123 -rfc -file dev.cer
Result(DOS Output):
Certificate stored in file <dev.cer>
4.Imported dev.cer in the keystore as using the command as... and selected y
keytool -import -v -file dev.cer -keystore tomcat.keystore -storepass server123
Result(DOS Output):
Owner: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Issuer: CN=KeshavClient, OU=AppDev, O=Netambit, L=Noida, ST=UP, C=IN
Serial number: 503c03cf
Valid from: Mon Aug 12 12:16:26 IST 2013 until: Sun Nov 10 12:16:26 IST 2013
Certificate fingerprints:
MD5: 7A:CE:AD:78:31:12:89:3A:20:94:01:63:5C:E6:6D:48
SHA1: 4C:E3:4A:CF:93:EF:69:46:AD:01:B1:AC:22:F4:E6:91:B5:62:D1:C3
SHA256: D1:E6:20:9C:A7:3C:82:46:7A:2A:E6:61:1E:30:E3:F0:B9:E6:F0:03:DA:
19:87:B4:6F:F2:B1:BE:D3:89:A8:2B
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AD 4A E3 0E 3D E9 DB B0 8E DF 8F 66 34 28 AE AF .J..=......f4(..
0010: 34 63 F2 4C 4c.L
]
]
Trust this certificate? [no]: y
Certificate was added to keystore
[Storing tomcat.keystore]
5.Added the connecter entry to server.xml as...
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="D:/server.keystore" keystorePass="server123"
truststoreFile="D:/server.keystore" truststorePass="server123"
clientAuth="true" sslProtocol="TLS" />
6. Started Tomcat, firefox and on Tools->Options->Advanced->View Certificates->Your Certificate->import, imported the dev.p12 file
Result: asked me for the password which I entered as dev123 then i hit next, next till finish
Final Result on opening https://localhost:8443/CertificatePOC/
Secure Connection Failed
An error occurred during a connection to localhost:8443.
SSL peer cannot verify your certificate.
(Error code: ssl_error_bad_cert_alert)
If in the server.xml I change the attribute clientAuth to false then the web page opens correctly.
Any help will be appreciated
I am using tomcat7 with eclipse indigo OS windows 7
If any more details/screenshot is required I will happily provide
The ssl_error_bad_cert_alert error in this case means the server doesn't trust your self-signed cert. One way to solve this is to generate certs and CSR's, and then sign them with a local development CA. Then you just add your dev CA to the JVM truststore. It is slightly more setup, but is more flexible (e.g., you can create signed certs for a whole development team, test revocation via OCSP/CRL, etc).
These steps are copied from my history and probably require changes:
Create a local dev CA
openssl genrsa -out ca.key -aes256 -passout pass:changeit 4096
openssl req -new -x509 -key ca.key -config openssl.conf -days 3560 -sha256 -out ca.pem -passin pass:changeit
openssl rsa -in ca.key -out ca.key -passin pass:changeit
Generate client and server keystores with a keypair in each
keytool -genkey -keyalg RSA -alias client -keystore client.jks -storepass changeit -validity 1000
keytool -genkey -keyalg RSA -alias tomcat -keystore ~/.keystore -storepass changeit -validity 1000
Generate client and server cert signing requests (csr) based on above keystore keypairs
keytool -certreq -v -alias client -keystore client.jks -storepass changeit -file client.csr
keytool -certreq -v -alias tomcat -keystore ~/.keystore -storepass changeit -file tomcat.csr
Sign the requests (create certs) for client/server csr's
openssl x509 -req -CA ca.pem -CAkey ca.key -in client.csr -out client.cer -days 1000 -CAcreateserial
openssl x509 -req -CA ca.pem -CAkey ca.key -in tomcat.csr -out tomcat.cer -days 1000 -CAcreateserial
Import the CA cert into client/server keystores (possibly not necessary, since it must be added to truststore anyway)
keytool -import -keystore client.jks -file ca.pem -alias rootca
keytool -import -keystore ~/.keystore -file ca.pem -alias rootca
Import the client and server certs into their respective keystores
keytool -import -keystore client.jks -file client.cer -alias client
keytool -import -keystore ~/.keystore -file tomcat.cer -alias tomcat
Convert the client cert to a p12 (PKCS12) so it can be imported into firefox or wherever
keytool -importkeystore -srckeystore client.jks -destkeystore client.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass changeit -deststorepass changeit -srcalias client -destalias client -srckeypass changeit -destkeypass changeit -noprompt
Import the CA cert into the JVM truststore
sudo keytool -import -trustcacerts -alias suter-dev-ca -file ca.pem -keystore /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre/lib/security/cacerts
Optionally, import the CA cert into your browser.
Your post was hard to read because of the formatting. Hope this helps.
Sources: http://shib.kuleuven.be/docs/ssl_commands.shtml, https://docs.oracle.com/cd/E19509-01/820-3503/ggezy/index.html
I am currently trying to enable a spnego based SSO Application.
As part of this I seek to get the delegated credentials.
How to verify that the credential I get after
GSSContext.acceptSecContext(gss, 0, gss.length); is a delegated credential or not.
GSSContext.getCredDelegState() is true.
My primary doubt is whether the server principal in the ticket should be
krbtgt/ABC.XYZ.COM#ABC.XYZ.COM or should be the service (HTTP/host.ABC.XYZ.com) for which the ticket was delegated?``
Delegated Credential is.....[GSSCredential:
client#ABC.XYZ.COM 1.2.840.113554.1.2.2 Initiate [Ticket (hex) =
0000: 61 81 F3 30 81 F0 A0 03 02 01 05 A1 0F 1B 0D 55 a..0...........A
0010: 53 2E 4F 52 41 43 4C 45 2E 43 4F 4D A2 22 30 20 BC.XYZ.COM."0
0020: A0 03 02 01 00 A1 19 30 17 1B 06 6B 72 62 74 67 .......0...krbtg
0030: 74 1B 0D 55 53 2E 4F 52 41 43 4C 45 2E 43 4F 4D t..ABC.XYZ.COM
0040: A3 81 B3 30 81 B0 A0 03 02 01 01 A1 03 02 01 01 ...0............
0050: A2 81 A3 04 81 A0 35 DF 47 76 64 F4 79 80 7C 2B ......5.Gvd.y..+
0060: 33 92 54 3B EA C8 F4 DE 62 19 37 AE BF 27 7C 9E 3.T;....b.7..'..
0070: BA 1D E6 BA B0 90 3D 2E 41 7E 41 0D 07 2A 2D AB ......=.A.A..*-.
0080: 33 88 11 40 69 CE 07 6E CE 84 C3 B1 95 22 CE 8B 3..#i..n....."..
0090: 76 98 01 61 C3 FA B7 CB 9F 95 C8 1F C7 AF F4 48 v..a...........H
00A0: 87 35 5D 83 CB D2 DA 86 56 2B 80 BC 33 CD A8 B8 .5].....V+..3...
00B0: 7B 8B 5E A2 D5 6C 27 F3 D6 ED 4E 77 17 68 7E C6 ..^..l'...Nw.h..
00C0: 85 00 9D B5 43 87 44 BC EA F5 67 12 12 96 B4 AE ....C.D...g.....
00D0: C6 B0 49 5C 08 9E 6F BB 7E E4 91 32 D0 0A 68 FA ..I\..o....2..h.
00E0: 9E 9C 6A 16 96 45 B6 87 58 86 ED 3B 12 EA 98 B8 ..j..E..X..;....
00F0: 6E A9 F9 3E D4 D1 n..>..
Client Principal = client#ABC.XYZ.COM
Server Principal = krbtgt/ABC.XYZ.COM#ABC.XYZ.COM
Session Key = EncryptionKey: keyType=1 keyBytes (hex dump)=
0000: 8F B5 AB AE B9 89 F1 5D
Forwardable Ticket true
Forwarded Ticket true
Proxiable Ticket false
Proxy Ticket false
Postdated Ticket false
Renewable Ticket false
Initial Ticket false
Auth Time = Mon Jun 17 03:53:45 PDT 2013
Start Time = Mon Jun 17 06:49:34 PDT 2013
End Time = Tue Jun 18 03:53:45 PDT 2013
Renew Till = null
Client Addresses Null ]]
I am using a linux based KDC and linux hosts for this.
Is there any reference to what the delegated ticket should be like?
The delegated ticket has been created for the UPN of your machine, if you use MIT/Heimdal KDC (no experience with) it's probably host/fqdn#REALM. In Windows (AD KDC) it is hostname$#REALM. Only that machine is able to extract the delegated credential.
The whole point of delegated credential is that there should be no difference between a delegated and a initial credential for an end service.
1)I am generating a Key file and a CSR with the help of openssl commands.
When displaying the CSR information with command “ openssl req -in test_csr.pem -noout –text” I get the following printings:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, O=Test
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a6:af:51:e9:23:65:50:27:14:83:f5:c8:11:10:
b1:03:0b:c7:0d:2d:ae:09:81:d9:f8:31:ad:8e:d7:
8e:65:a8:e0:d4:b4:7e:f9:3e:99:fa:b0:43:5d:e0:
41:7a:ee:9f:90:3d:05:c0:6f:80:bb:bb:9e:dd:64:
1e:15:89:0c:bc:e6:3d:76:4e:d0:ef:5c:e4:de:34:
00:d0:ac:5c:e4:f8:73:b7:22:12:81:30:28:85:cd:
5a:bb:d6:28:c3:dc:01:67:f5:56:3a:3f:01:f3:d7:
8f:d9:19:67:90:1e:23:24:b0:58:e9:80:44:c9:36:
ae:2b:c3:81:a3:ce:de:af:8b:32:33:7d:f7:81:d7:
80:b8:d2:97:ce:8b:f3:21:2b:e8:e2:96:d0:b1:3f:
cc:dc:18:18:c1:e7:99:81:2a:e9:45:20:b7:80:39:
b3:5d:b3:ab:61:6a:61:f3:e1:7c:32:b7:a8:29:1a:
b2:e1:02:81:42:1f:b4:c3:7f:bf:21:f6:2d:4f:ec:
19:d4:3a:d4:bf:90:8a:3b:f0:24:cf:83:1b:21:ab:
b2:cb:15:38:f2:ac:1d:80:ba:33:2b:c8:f4:8d:52:
90:7a:25:2b:e5:08:68:a2:f2:84:61:2f:24:48:a9:
25:97:85:28:64:52:f9:15:91:eb:36:c6:d9:98:08:
09:d3
Exponent: 65537 (0x10001)
Attributes:
a0:00
Now when I edit the key file in DER format with an Hex editor, I get the following data
30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 A6 AF 51 E9 23 65 50 27 14 83 F5 C8 11 10 B1 03 0B C7 0D 2D AE 09 81 D9 F8 31 AD 8E D7 8E 65 A8 E0 D4 B4 7E F9 3E 99 FA B0 43 5D E0 41 7A EE 9F 90 3D 05 C0 6F 80 BB BB 9E DD 64 1E 15 89 0C BC E6 3D 76 4E D0 EF 5C E4 DE 34 00 D0 AC 5C E4 F8 73 B7 22 12 81 30 28 85 CD 5A BB D6 28 C3 DC 01 67 F5 56 3A 3F 01 F3 D7 8F D9 19 67 90 1E 23 24 B0 58 E9 80 44 C9 36 AE 2B C3 81 A3 CE DE AF 8B 32 33 7D F7 81 D7 80 B8 D2 97 CE 8B F3 21 2B E8 E2 96 D0 B1 3F CC DC 18 18 C1 E7 99 81 2A E9 45 20 B7 80 39 B3 5D B3 AB 61 6A 61 F3 E1 7C 32 B7 A8 29 1A B2 E1 02 81 42 1F B4 C3 7F BF 21 F6 2D 4F EC 19 D4 3A D4 BF 90 8A 3B F0 24 CF 83 1B 21 AB B2 CB 15 38 F2 AC 1D 80 BA 33 2B C8 F4 8D 52 90 7A 25 2B E5 08 68 A2 F2 84 61 2F 24 48 A9 25 97 85 28 64 52 F9 15 91 EB 36 C6 D9 98 08 09 D3 02 03 01 00 01
I observe that in addition to the Key (from byte 33) as is it displayed in the previous step, there is extra data before the key (32 first bytes) and after the key (5 last bytes).
Does somebody know where the extra information comes from and how to decrypt it?
2)I have to test a configuration where the pair of the Keys (private and public) and the hash signature are generated in a smart card with the help of vendor API’s. With a first API I get the Public Key and Length from the smart card. With a second API I a get the hash signature data and length.
I guess that the Public key can be inserted in the CSR with openssl X509_REQ_set_pubkey API (is it correct?).
The question is: Is there an existing openssl API I can use to insert the hash signature in the CSR (something like X509_REQ_sign but without hashing and signature process that has already been done by the smart card).
Thanks.
P.L.
First 256 bytes should be structure describing certificates owner (Subject, algorithm, etc).
Last 5 bytes is the RSA public exponent - 65537 in ASN.1 encoding.
To get more information use ASN.1 decoder (or openssl asn1parse command).
Unfortunately I don't know about such function on OpenSSL and don't have time to dig into their sources, but at least it is possible to form CSR ASN.1 structure manually, that's not that hard.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I've encountered a serious bug in OpenSSL 1.0.1 on Ubuntu 12.04:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665452
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666051 <- dated Oct 3 2012!
The gist of it is that I'm able to connect to some servers but not others. Connecting to google works:
openssl s_client -connect mail.google.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
...
Protocol : TLSv1.1
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 94DB1AC8531115C501434B16A5E9B735722768581778E4FEA4D9B19988551397
Session-ID-ctx:
Master-Key: 8694BF510CD7568CBAB39ECFD32D115C511529871F3030B67A4F7AEAF957D714D3E94E4CE6117F686C975EFF21FB8708
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - fb 52 d6 d3 3c a8 75 e1-1f 1d f6 23 ab ce 55 44 .R..<.u....#..UD
0010 - 27 bf ad c4 7a 0d 83 c8-48 59 48 4b 39 bb 3c c7 '...z...HYHK9.<.
0020 - 01 1e ad b3 13 de 65 d4-e8 ea e4 35 89 83 55 8e ......e....5..U.
0030 - e4 d5 9f 60 58 51 33 9b-83 34 b9 35 3d 46 cb a3 ...`XQ3..4.5=F..
0040 - 35 7b 48 5d 7b 86 5c d5-a1 14 9d 8c 3e 93 eb fb 5{H]{.\.....>...
0050 - ac 78 75 72 9b d2 bc 67-f2 fa 5b 75 80 a6 31 d8 .xur...g..[u..1.
0060 - 71 15 85 7f 55 4d dc fb-b0 b5 33 db 6d 36 8c c6 q...UM....3.m6..
0070 - e8 f9 54 7a 29 69 87 2c-dd f3 c5 cf 26 55 6f 6e ..Tz)i.,....&Uon
0080 - 45 73 7a 1d e4 b3 be b2-92 3f 0b ed c4 1c a5 24 Esz......?.....$
0090 - 3c f0 ca a5 <...
Start Time: 1354063165
Timeout : 300 (sec)
Verify return code: 0 (ok)
But connecting to facebook doesn't:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt -cipher SRP-AES-256-CBC-SHA
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0xddd2c0 [0xddd340] (64 bytes => 64 (0x40))
0000 - 16 03 01 00 3b 01 00 00-37 03 02 50 b5 5d 75 42 ....;...7..P.]uB
0010 - c2 78 55 49 b5 2e de 4f-00 a6 a8 d5 cf 10 92 44 .xUI...O.......D
0020 - 28 62 34 d6 61 5e 88 c3-68 8b 96 00 00 04 c0 20 (b4.a^..h......
0030 - 00 ff 02 01 00 00 09 00-23 00 00 00 0f 00 01 01 ........#.......
>>> TLS 1.1 [length 003b]
01 00 00 37 03 02 50 b5 5d 75 42 c2 78 55 49 b5
2e de 4f 00 a6 a8 d5 cf 10 92 44 28 62 34 d6 61
5e 88 c3 68 8b 96 00 00 04 c0 20 00 ff 02 01 00
00 09 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
read from 0xddd2c0 [0xde28a0] (7 bytes => 7 (0x7))
0000 - 15 03 02 00 02 02 28 ......(
SSL3 alert read:fatal:handshake failure
<<< TLS 1.1 [length 0002]
02 28
SSL_connect:error in unknown state
140581179446944:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 64 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
The facebook connection either hangs after the client sends its hello buffer and never receives the server hello response, or returns with an error code if I pass in a cipher it recognizes. This happens with both -tls1 and -ssl3. I've tried every parameter to openssl I can think of.
apt-cache showpkg openssl
...
Provides:
1.0.1-4ubuntu5.5 -
1.0.1-4ubuntu5.3 -
1.0.1-4ubuntu3 -
I've also tried every parameter I can think of to curl but with no success, because it uses openssl under the hood.
I'm concerned that Ubuntu can't establish secure connections (an astounding statement, I realize). After two solid days of beating my head against this problem, I'm basically praying at this point that someone knows a workaround. I'm considering a downgrade to OpenSSL 1.0.0 or using libcurl4-dev with gnutls-dev instead. Both solutions leave a rotten taste in my mouth. Thanks in advance for any help you can provide.
P.S. all of this work is so that my server can interface with external https REST APIs. I consider this a fundamental requirement in any webserver today, no excuses.
UPDATE: Here is my output without passing a cipher. It doesn't matter if I pass -CAfile or not either:
openssl s_client -connect graph.facebook.com:443 -debug -state -msg -CAfile /etc/ssl/certs/ca-certificates.crt
CONNECTED(00000003)
SSL_connect:before/connect initialization
write to 0x14ed1a0 [0x1515bf0] (226 bytes => 226 (0xE2))
0000 - 16 03 01 00 dd 01 00 00-d9 03 02 50 b6 39 78 6a ...........P.9xj
0010 - 24 95 8e dc 62 19 37 4b-ab 77 b8 66 cd 48 ba a2 $...b.7K.w.f.H..
0020 - a1 2a f8 1d f8 c9 5d fb-9d db 84 00 00 66 c0 14 .*....]......f..
0030 - c0 0a c0 22 c0 21 00 39-00 38 00 88 00 87 c0 0f ...".!.9.8......
0040 - c0 05 00 35 00 84 c0 12-c0 08 c0 1c c0 1b 00 16 ...5............
0050 - 00 13 c0 0d c0 03 00 0a-c0 13 c0 09 c0 1f c0 1e ................
0060 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 0e c0 04 .3.2.....E.D....
0070 - 00 2f 00 96 00 41 c0 11-c0 07 c0 0c c0 02 00 05 ./...A..........
0080 - 00 04 00 15 00 12 00 09-00 14 00 11 00 08 00 06 ................
0090 - 00 03 00 ff 02 01 00 00-49 00 0b 00 04 03 00 01 ........I.......
00a0 - 02 00 0a 00 34 00 32 00-0e 00 0d 00 19 00 0b 00 ....4.2.........
00b0 - 0c 00 18 00 09 00 0a 00-16 00 17 00 08 00 06 00 ................
00c0 - 07 00 14 00 15 00 04 00-05 00 12 00 13 00 01 00 ................
00d0 - 02 00 03 00 0f 00 10 00-11 00 23 00 00 00 0f 00 ..........#.....
00e0 - 01 01 ..
>>> TLS 1.1 [length 00dd]
01 00 00 d9 03 02 50 b6 39 78 6a 24 95 8e dc 62
19 37 4b ab 77 b8 66 cd 48 ba a2 a1 2a f8 1d f8
c9 5d fb 9d db 84 00 00 66 c0 14 c0 0a c0 22 c0
21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 02
01 00 00 49 00 0b 00 04 03 00 01 02 00 0a 00 34
00 32 00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09
00 0a 00 16 00 17 00 08 00 06 00 07 00 14 00 15
00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0f
00 10 00 11 00 23 00 00 00 0f 00 01 01
SSL_connect:unknown state
Why are you passing -cipher SRP-AES-256-CBC-SHA when connecting to graph.facebook.com? Facebook certainly doesn't support SRP: http://srp.stanford.edu/.
Does it work if you don't pass that?
Also, can you give the IP address that you're getting? With 69.171.229.17, I can reproduce that exact ClientHello (modulo the nonce and with RC4-SHA are the only cipher save the SCSV) and I get a successful handshake.
Lastly, have you tried doing over an SSH tunnel to somewhere else? Sadly, when deploying TLS features in Chrome we have repeatedly found networking hardware that breaks TLS connections. (Although I can't think of a case where -ssl3 wouldn't fix it unless the hardware was actively trying to censor connections.)
Setting the MTU on my Ubuntu box from 1500 to 1496 (due to one of our firewalls being set too low) allows me to receive a response from the server without having to reboot (be sure to call ifconfig first and write down your original MTU which should be 1500):
sudo ifconfig eth0 mtu 1496
I discovered my MTU by pinging with successively larger buffers (add 28 bytes for UDP header):
Fails for 1472 + 28 = 1500:
ping -s 1472 facebook.com
PING facebook.com (66.220.158.16) 1472(1500) bytes of data.
...
Works for 1468 + 28 = 1496:
ping -s 1468 facebook.com
PING facebook.com (69.171.229.16) 1468(1496) bytes of data.
1476 bytes from www-slb-ecmp-06-prn1.facebook.com (69.171.229.16): icmp_req=1 ttl=242 time=30.0 ms
...
With 1496 I'm now able to curl to facebook.com:
curl -v https://facebook.com
* About to connect() to facebook.com port 443 (#0)
* Trying 66.220.152.16... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=California; L=Palo Alto; O=Facebook, Inc.; CN=www.facebook.com
* start date: 2012-06-21 00:00:00 GMT
* expire date: 2013-12-31 23:59:59 GMT
* subjectAltName: facebook.com matched
* issuer: O=VeriSign Trust Network; OU=VeriSign, Inc.; OU=VeriSign International Server CA - Class 3; OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: facebook.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.facebook.com/
< Content-Type: text/html; charset=utf-8
< X-FB-Debug: 3vAg1O5OG9hB/EWC+gk1Kl3WLJRGmlQDaEodirWb+i0=
< Date: Wed, 28 Nov 2012 19:52:25 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host facebook.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
I personally think that MTU should have absolutely nothing to do with what the user sees at the stream level with TCP so I hope the OpenSSL folks fix this. I also wish that someone would invent an automagic bug submitter for bugs that are profoundly widespread and time-sucking.