Hello all,
Affected: FortiOS 6 to 7.2.4. Webbrowser, Devices, everything that is not Windows.
If you have Certificate Inspection, deep inspection enabled, Windowsupdates are not possibel anymore. To only way is to import the CA in the Fortigate. But the question arises, why was this CA not integrated into any Windows devices?
Example: https://sls.update.microsoft.com
i noticed that the Microsoft Update Secure Server CA 2_1 certificate is not trusted by Fortigate.
But not only that. This certificate is not trusted at all. From no device, no website, no tool. Only Microsoft Windows itself has this CA on board. How can that be?
openssl s_client -connect sls.update.microsoft.com:443
CONNECTED(00000003)
depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 2.1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = WA, L = Redmond, O = Microsoft, OU = DSP, CN = sls.update.microsoft.com
verify return:1
---
Certificate chain
0 s:C = US, ST = WA, L = Redmond, O = Microsoft, OU = DSP, CN = sls.update.microsoft.com
i:C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 2.1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Apr 27 19:46:13 2023 GMT; NotAfter: Apr 27 19:46:13 2024 GMT
1 s:C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 2.1
i:C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Root Certificate Authority 2011
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 21 17:33:35 2012 GMT; NotAfter: Jun 21 17:43:35 2027 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGQjCCBCqgAwIBAgITMwAAAddhBWmNlzCE0QAAAAAB1zANBgkqhkiG9w0BAQsF
ADCBhDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcT
B1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEuMCwGA1UE
AxMlTWljcm9zb2Z0IFVwZGF0ZSBTZWN1cmUgU2VydmVyIENBIDIuMTAeFw0yMzA0
MjcxOTQ2MTNaFw0yNDA0MjcxOTQ2MTNaMHExCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYD
VQQLEwNEU1AxITAfBgNVBAMTGHNscy51cGRhdGUubWljcm9zb2Z0LmNvbTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMlEb/FONdbWgXAgHslWDMAChdLu
I3uShHerlz62/N8Qfl2W70+WOWWCI+BNhMglsAK7jc3Z2qpTQDqseQcgEARJgqRC
dNlDcYMWMKvoKlPV7mg/dak+tEAZWk6a1+Cfusnr8biPZmg82S/C0iLc7K6P4vUh
BW3L3j07LhJNCn+8dR2gl7ByvLWrjXhZTIDW8HSG79eu07LLgHJaHBD23+AZx+mz
hbcwbADyb1FyH9HzqFcohcHkBfOiDBR1ApZonnpzWPi86xTRMY2tFoWHwZvonhW8
6BP7lH2CsMs2GRilPkvS/Db1emWqP3EH6GOXBodQ73VtYheD/DnDrJjtuR0CAwEA
AaOCAb0wggG5MA4GA1UdDwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEFBQcDATAM
BgNVHRMBAf8EAjAAMGMGA1UdEQRcMFqCGHNscy51cGRhdGUubWljcm9zb2Z0LmNv
bYIaKi5zbHMudXBkYXRlLm1pY3Jvc29mdC5jb22CIiouYmFja2VuZC5zbHMudXBk
YXRlLm1pY3Jvc29mdC5jb20wHQYDVR0OBBYEFGMmywn+t07ay1ufyzVVJ7ILs2Ai
MB8GA1UdIwQYMBaAFNLyPYR0hhtQhapd5aUHmvBH0y5pMGgGA1UdHwRhMF8wXaBb
oFmGV2h0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2lvcHMvY3JsL01pY3Jvc29m
dCUyMFVwZGF0ZSUyMFNlY3VyZSUyMFNlcnZlciUyMENBJTIwMi4xLmNybDB1Bggr
BgEFBQcBAQRpMGcwZQYIKwYBBQUHMAKGWWh0dHA6Ly93d3cubWljcm9zb2Z0LmNv
bS9wa2lvcHMvY2VydHMvTWljcm9zb2Z0JTIwVXBkYXRlJTIwU2VjdXJlJTIwU2Vy
dmVyJTIwQ0ElMjAyLjEuY3J0MA0GCSqGSIb3DQEBCwUAA4ICAQABgfB0eBm4rpT5
lyXOVF7ZhP/j/dAc9KEBkHQnjYgMEdn8CWrya1WDceqJOQ/eK2lMSZ7+6V3k15OY
tcNgqUMMDfeSxTqR7lhEJU9WUryt6Sd+EO7L/CQdn6PSajX7VWmHvUqio6HQ7g82
QgGRPKKNM+kaqS4BkRITp2d54NPGckVlaJVgnqm3laH359kvXJzXOEX9+d1T/HVi
giGxsS+lXn7PYZpIpHbMNd7q176OLWs0SYejgiLDjaUescOP0JD9/W5UhmvCXt5U
8bDV+YV1eGJDon2koEjPSOMZ70G+6zFRXeWoF0To7TTP9v2VOZ9UIaDG+LLOkXoj
Tu6cMazxndCCcXdSsw5LwB9GanW21bB7d122jm3Hts80ehvgEEB7fvsqGp0MkWIW
qdAKPzn4/B4W7TcAFiixHHNNyehCaaFFVa6+lpTG0h/y6NfUQokZFg21uUmYhcqb
9aN92epeFJBQDRy0cwSGvMiyDbgpF1lvnH+kpmPv0r8aVqpx+lov0aSuvKEa8tq3
uc9s4+6OhlKSqz4Lxdb6nB26fdxGlZC27Qt9WePRVxPXs/lDT9yaF3IJ+EflZuj2
ZREeJnDrcGBR+oO3H8s+pntS3rC1OCOGgIEt+psTOpHYEBXeXhQ/kYolGZtfDUNx
VjpougozgYMK/6EqAO7O3PUwaNU5bw==
-----END CERTIFICATE-----
subject=C = US, ST = WA, L = Redmond, O = Microsoft, OU = DSP, CN = sls.update.microsoft.com
issuer=C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 2.1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, secp384r1, 384 bits
---
SSL handshake has read 4055 bytes and written 805 bytes
Verification error: unable to get local issuer certificate
---
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: 20 (unable to get local issuer certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 7CE448A3D9D152CF2BEE6A4AD13E97556DC2B36D7FA9748559A11CA4BD30A3A3
Session-ID-ctx:
Resumption PSK: 71298C1346409F32C3E5E2A1302A0EBAFE29887FBA7F66E38AA0BF6AEAF2CA4D68CF835B361095EBBCFECFF10697E374
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 36000 (seconds)
TLS session ticket:
0000 - c9 35 00 00 e4 4c 44 cd-ca 81 e7 59 0b 6c da 76 .5...LD....Y.l.v
0010 - bb d7 c8 4c 79 ab 62 32-a3 30 7e a8 41 c4 90 3d ...Ly.b2.0~.A..=
Start Time: 1705709761
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
Also in Microsoft Edge on Linux, this CA is not there. You can think about it... strange.
CA Attached:
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
This looks like a Microsoft choice, the root CA (Microsoft Root Certificate Authority 2011) they chose for this service is not publicly trusted and is only present on the trusted root CA on windows and also the intermediate certificate (Microsoft Update Secure Server CA 2.1) is missing.
Surprisingly Mozilla has this complete trust chain under Authorities, on other systems it has to be manually imported.
Hello,
Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Thanks,
This looks like a Microsoft choice, the root CA (Microsoft Root Certificate Authority 2011) they chose for this service is not publicly trusted and is only present on the trusted root CA on windows and also the intermediate certificate (Microsoft Update Secure Server CA 2.1) is missing.
Surprisingly Mozilla has this complete trust chain under Authorities, on other systems it has to be manually imported.
So does this mean that as soon as you use Certificate Inspection or deep inspection on the Fortigate, the Microsoft certificate MUST be imported into the Fortigate, right?
Yes correct, usually it will be treated as a normal private CA and should be blocked
only this two Microsoft certs seems loaded by default (at least on my FGT):
Well, then it's exactly the same as I was able to understand here. I don't agree at all with Microsoft's behaviour in this case. :thinking_face::squinting_face_with_tongue::eyes:
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1665 | |
1077 | |
752 | |
446 | |
220 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.