
NikhilB.39642 (Customer) asked a question.
Trying to understand the impact for our org. What do you mean by limited or non-standard set of certificates? We use an okta.com subdomain and a custom domain name owned by us. What specifically requires an update?

I ran a curl request on a proxied system: curl https://okta-cert-test.okta.com/index.html --verbose
I don't get the expected "SSL request verify OK" response. I get the following:
* Trying 13.249.42.6...
* TCP_NODELAY set
* Connected to okta-cert-test.okta.com (13.249.42.6) port 443 (#0)
* schannel: SSL/TLS connection with okta-cert-test.okta.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 188 bytes...
* schannel: sent initial handshake data: sent 188 bytes
* schannel: SSL/TLS connection with okta-cert-test.okta.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with okta-cert-test.okta.com port 443 (step 2/3)
* schannel: encrypted data got 3941
* schannel: encrypted data buffer: offset 3941 length 4096
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with okta-cert-test.okta.com port 443
* schannel: clear security context handle
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
If I go to the url in a browser I get: Okta Cert Test Successful
Not sure if I have to take additional steps.
On a non proxied system I get
* Trying 13.249.42.6:443...
* Connected to okta-cert-test.okta.com (13.249.42.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: C:\IdealIT\curl\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Okta, Inc.; CN=*.okta.com
* start date: Apr 1 00:00:00 2021 GMT
* expire date: May 2 23:59:59 2022 GMT
* subjectAltName: host "okta-cert-test.okta.com" matched cert's "*.okta.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)........................................
That looks like it's working properly. I'm going to open a ticket with Okta to see if I need to do anything with the proxy. If anyone needs curl https://curl.se/download.html
@NikhilB.39642 (Customer) - The new certificate is different from the current one in that it is issued by a different certificate authority. You just need to make sure that your systems have the matching root and intermediate certificates in your local certificate store so that your systems can validate the entire certificate chain. If the chain can't be validated, your system won't trust the new certificate and you'll get trust- or validation-related errors when you connect.