[SOLVED] The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel

[fborup]

I´m trying to do a trial/experiment, using the community edition, version 5

So, i´ve installed a brand new WIn2019 VM, got to install for O365 and SharePoint only to do some tests

At first, there was a problem at the install, I had to download and manually install CA and Subordinate certificates for Digifort/Baltimore to complete the install.

Now is OK, I was bale to create a local repositiry and now, i´m stuck creating the S3 AWS Bucket repository

All errors related to TLS/SSL

The weird part is, the internet access is unrestricted, I can access all mentioned URLS with no problem
I already tried different ways tio authenticate, the mentioned URLs for revocation are accessible via Browser

===================================================================================================
Adding organization...
Loading certificates...
Certificates loaded
Error: The collection has been marked as complete with regards to additions.
Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
===================================================================================================
Obtaining device code (resource: https://graph.microsoft.com/, authentication endpoint: https://login.microsoftonline.com/common, client ID: 04b07795-8ddb-461a-bbee-02f9e1bf7b47)...
Validating certificate...
Warning: Certificate chain error status: UntrustedRoot. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
===================================================================================================
Getting internet proxy for 'https://outlook.office365.com/powershell-liveid'...
Internet proxy is disabled
Failed to connect to PowerShell
Error: Connecting to remote server outlook.office365.com failed with the following error message : The server certificate on the destination computer (outlook.office365.com:443) has the following errors:
The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable.
The SSL certificate is signed by an unknown certificate authority. For more information, see the about_Remote_Troubleshooting Help topic.
===================================================================================================


I tried :

$TLS12Protocol = [System.Net.SecurityProtocolType] 'Ssl3 , Tls12'
[System.Net.ServicePointManager]::SecurityProtocol = $TLS12Protocol

No luck!

Any idea?

[Mike Resseler]

The only thing I can think off... Is there a firewall between the VM and the internet? It might be that it is doing TLS/SSL inspections and it might be best that you exclude M365 ULRs from that inspection

[nielsengelen]

As Mike states, most likely you have a firewall web filter on for these sites which blocks it. If this is enabled, you won't be able to access OneDrive/SharePoint properly.

[fborup]

Yes, there is a firewall, but is in transparent mode and no UTM features applied, just passing through traffic with no intervention. For good measure I´ve disabled the ASIC and NPU offloading to make sure that no accelaretaion is taking place.

IISCrypt and Digicert tool are telling me that SHA-1 is allowed (some roots are using) and digicert tool show me proper certificate information

My theory: Something is stopping certs to be verified (default Win2019 isntallation), so, what I did today:
I enter into a more modern browser, instead IE, i gathered all root and subordinates information possible, download some PEM files and PEM chains, forced into the trusted root store and.. SOME URls are now ok, but others don´t. There are too many redirects, i´m not sure if Im covering all possible CAs on the chains, but things started to go forward a little bit

The digicert tool, is showing me that config for automatic update of certificates are in place, so, in theory, the system should be able to get a cert and verify its chain, subs, root and gather all information automatically, but it not appears to be the case

[fborup]

New info, some WGET tests are returning somewhat confusing information



wget https://graph.microsoft.com
WARNING: Certificate verification error for graph.microsoft.com: unable to get local issuer certificate
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://developer.microsoft.com/graph [following]
--16:12:39-- https://developer.microsoft.com/graph
=> `graph'
Resolving developer.microsoft.com... 23.55.34.245
Connecting to developer.microsoft.com|23.55.34.245|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unable to establish SSL connection.






wget https://login.microsoftonline.com --no-check-certificate
WARNING: Certificate verification error for login.microsoftonline.com: unable to get local issuer certificate
WARNING: certificate common name `graph.windows.net' doesn't match requested host name `login.microsoftonline.com'.
HTTP request sent, awaiting response... 302 Found
Location: https://www.office.com/login# [following]
--16:13:25-- https://www.office.com/login
=> `login'
Resolving www.office.com... 13.107.9.156
Connecting to www.office.com|13.107.9.156|:443... connected.
Unable to establish SSL connection.



wget https://outlook.office365.com --no-check-certificate
WARNING: Certificate verification error for outlook.office365.com: unable to get local issuer certificate
WARNING: certificate common name `outlook.com' doesn't match requested host name `outlook.office365.com'.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://outlook.office365.com/owa/ [following]
WARNING: Certificate verification error for outlook.office365.com: unable to get local issuer certificate
WARNING: certificate common name `outlook.com' doesn't match requested host name `outlook.office365.com'.

[fborup]

Now, i´m ready to close this thread, because I found one more CA cert not trusted in the chain, when accessing "graph.microsoft.com", an once the CA root was inserted into the trusted store, it helped to go to next level.

It´s not working yet, but the thread can be closed

[Mike Resseler]

Thanks for the additional information, but you are saying it is not working yet so...

I am a bit surprised that the CA root from graph.microsoft.com is not in the default installation to be honest. We test our solution on Windows 2k19 and we never had such an issue.