Suddenly, after a recent update of Ubuntu, an attempt to access an Outlook Web site resulted in a Privacy Error that prevents sign in unless the warning is overriden. (See attachment below.) This error occurs on two different browsers, Chrome and Firefox, on my Ubuntu computer and the error does not occur when using any other computer (Windows or Linux Lite). Thanks in advance for any suggestions on how to fix this problem.
This looks suspiciously like a self signed certificate which would normally be considered invalid, not sure how/why Windows or linux lite would not mark it like that … (but lets see what the curl command returns)
Secure TLS certificates always need to be counter signed by a certificate Authority (CA), Ubuntu ships by default the full list and public keys of CAs so certs can be verified against them, self signed certs simply have not been counter signed by a CA
SSL certificate problem: unable to get local issuer certificate
closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
And I too was confused by why Ubuntu but not Linux Lite or Windows rejected the certificate, but I’m quite certain that I received no warnings navigating to the site on computers with either Linux Lite or Windows, and I had no trouble on Ubuntu either until an update about a week ago.
SSL certificate problem: unable to get local issuer certificate
closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
Not a lot beyond contacting the server admins, the server does not seem to even send proper CA info:
$ openssl s_client -connect mercury.law.nyu.edu:443
[...]
subject=DC=org, DC=incommon, C=US, ST=New York, O=New York University, CN=mercury.law.nyu.edu
issuer=C=US, O=Internet2, CN=InCommon RSA IGTF Server CA 3
---
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 2581 bytes and written 416 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---
[...]
This “No client certificate CA names sent” looks mis-configured to me
Checked: I can access the site without security warnings on Ubuntu 24.04.2 using either Firefox or Chromium.
How odd is that? Seems every computer with any operating system other than mine can connect to the site, but mine cannot (and that’s having tried two browsers).
[Yes, I believe I restarted the computer after the update, but I’ll try that again next time I’m home with the computer.]
This server could not prove that it is mercury.law.nyu.edu; its security certificate is not trusted by your computer’s operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.
So, although rebooting after updating the certificates didn’t help, here is something odd that I discovered: No Error messages when the server is accessed in Incognito mode. Does that give anyone any idea of what’s wrong? More curious than anything else at this point.
I have never had to go past the above to solve it.
I too checked:
Results
openssl s_client -connect mercury.law.nyu.edu:443
Connecting to 128.122.159.101
CONNECTED(00000003)
depth=0 DC=org, DC=incommon, C=US, ST=New York, O=New York University, CN=mercury.law.nyu.edu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 DC=org, DC=incommon, C=US, ST=New York, O=New York University, CN=mercury.law.nyu.edu
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 DC=org, DC=incommon, C=US, ST=New York, O=New York University, CN=mercury.law.nyu.edu
verify return:1
Certificate chain
0 s:DC=org, DC=incommon, C=US, ST=New York, O=New York University, CN=mercury.law.nyu.edu
i:C=US, O=Internet2, CN=InCommon RSA IGTF Server CA 3
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Oct 16 00:00:00 2024 GMT; NotAfter: Oct 16 23:59:59 2025 GMT
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 2581 bytes and written 410 bytes
Verification error: unable to verify the first certificate
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
Start Time: 1743713240
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
Max Early Data: 0
Start Time: 1743713240
Timeout : 7200 (sec)
Verify return code: 21 (unable to verify the first certificate)
Extended master secret: no
Max Early Data: 0
read R BLOCK
80DB19C6C0720000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:688:
This did the trick, thank you. Funny thing is that, not too long ago, I was a Google Photos product expert (all volunteer, like this site), and I had a canned answer to half a dozen problems suggesting clearing the cache and cookies. Somehow, though, it did not occur to me to try this here. Glad you were smarter. Thanks again.