If you have installed WatchGuard System Manager, a copy of each certificate is stored on your hard drive at: ![]() However, you can also import certificates from other CAs so that your certificates are trusted. We recommend that you import certificates signed by a CA on this list for the HTTPS proxy or Fireware Web UI, so that users do not see certificate warnings in their web browser when they use those features. > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.Certificate Authorities Trusted by the Deviceīy default, your Firebox trusts most of the same certificate authorities (CAs) as most modern web browsers. > openssl s_client -quiet -connect :3389 -CApath ~/empty/ -CAfile gdroot-g2.crt So the in tests below, you're not getting more than *default* CAfile and CApath when you don't specify either on theĬommand-line, and you don't disable these with "-no-CAfile" or Note that to reduce WTF surprises, OpenSSL 1.1.x only loads the Probably still finds the right CA in the default CApath or CAfile. > $ openssl s_client -quiet -connect :3389 -CApath ~/empty/ -CAfile gdroot-g2.crt > $ openssl s_client -quiet -connect :3389 -CApath ~/empty/ -CAfile sfroot-g2.crt ![]() > depth=0 OU = Domain Control Validated, CN = > depth=1 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", OU =, CN = Starfield Secure Certificate Authority - G2 > depth=2 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2 > $ openssl s_client -quiet -connect :3389 Sure that only the trusted certificates you want to test are used. You need to point SSL_CERT_DIR toĪn empty directory and SSL_CERT_FILE at the desired CAfile to make *default* CAfile and default CApath, in *addition* to any CAfileĪnd CApath you might specify. Note that in OpenSSL 1.0.2, the "s_client" command *always* loads the The chain "extended Key Usage" is checked more consistently in > to know what really is going on - what changed to cause this. > I now have a work-around to make this application work, but I would like "TLS Web Server" (really TLS server) when doing certificate verification. To specify that purpose, but FreeRDP may not specify its peer as a It is valid, but has a restricted purpose. And, the new version makes more extensive checks that > openssl version of the CA is not valid, because it says "Web Server > Since I am trying to make a RDP connection, does this mean that the If your application does not specify "serverAuth" as the "purpose"īeing verified, then verification should fail. Is part of a "TRUSTED CERTICATE" encapsulation of a CA certificate,Īnd can be used to limit the "purpose" for which a certificate is Well, that's "auxiliary" trust data outside the certificate. > Alias: Starfield Root Certificate Authority - G2 > The only difference is that the one from openssl ends with: > openssl x509 -in /var/lib/ca-certificates/pem/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text > openssl x509 -in /var/lib/ca-certificates/openssl/Starfield_Root_Certificate_Authority_-_G2.pem -noout -text > on the two systems - they are a binary match.īut they're not the same, only the encapsulated X.509 certificatesĪre the same, but one is wrapped as a "trusted certificate" with a > Starfield_Root_Certificate_Authority_-_G2.pem in the openssl directory > setting SSL_CERT_DIR to /var/lib/ca-certificates/pem/ - this made > (which seems to be the default, and did not change anything), and then > Then, I tested setting SSL_CERT_DIR to /var/lib/ca-certificates/openssl Self-signed root that has never signed any certificates into CAfile,Ĭan be one test to check that your application fails when it should I don't believe I suggested setting SSL_CERT_FILE to an emptyĭirectory, or an empty file. > empty directory and the CA file - did not help. > I tested the application, setting SSL_CERT_DIR and SSL_CERT_FILE, to the With old, but not the new code? For meaningful tests you need toĮxplicitly override both, and place just specific CA certs in CAfile, Perhaps you did not override CApath? And the default CApath succeeds (Results attached.) I guess the new version is better at checking ![]() > file - the only time it failed was on the new version, with the wrong > pointing to the correct CA, and with CAfile pointing to the WRONG CA > I tested using s_client, on both systems, with no options, with CAfile
0 Comments
Leave a Reply. |