0

In HTTP The Definitive Guide

When you establish a secure web transaction through HTTPS, modern browsers automatically fetch the digital certificate for the server being connected to. If the server does not have a certificate, the secure connection fails.

When the browser receives the certificate, it checks the signing authority. If it is a public, well-respected signing authority, the browser will already know its public key (browsers ship with certificates of many signing authorities preinstalled), so it can verify the signature as we discussed in the previous section, “Digital Signatures.” If the signing authority is unknown, the browser isn’t sure if it should trust the signing authority and usually displays a dialog box for the user to read and see if he trusts the signer. The signer might be the local IT department, or a software vendor.

How does a browser check the signing authority, after receiving a certificate from a server?

  • Does the browser need to get the public key from the signer, in order to verify the server certificate?

  • Are public keys of CAs and server certificates of servers stored separately?

  • Does the browser permanently store the received server certificate somewhere, or delete them after the HTTP session or some expiration date?

    If the computer which runs the browser also run a web server to host some web applications using HTTPS and server certificates, are those server certificates for the locally hosted web applications and the server certificates received by the local browser stored separately?

In Using Curl to Automate HTTP Jobs:

curl also tries to verify that the server is who it claims to be, by verifying the server's certificate against a locally stored CA cert bundle. Failing the verification will cause curl to deny the connection. You must then use --insecure (-k) in case you want to tell curl to ignore that the server can't be verified.

At times you may end up with your own CA cert store and then you can tell curl to use that to verify the server's certificate:

curl --cacert ca-bundle.pem https://example.com/

How does curl check the signing authority?

  • Is "verifying the server's certificate against a locally stored CA cert bundle ca-bundle.pem" how curl checks the signing authority?

  • What is inside a locally stored CA cert bundle ca-bundle.pem?(I guess the bundle doesn't contain server certificates, because curl fetches server certificates directly from servers.)

    If the computer which runs curl also run a web server to host some web applications using HTTPS and server certificates, are those server certificates for the locally hosted web applications and the locally stored CA cert bundle used by the local curl stored separately?

Thanks.

Tim
  • 647
  • 3
  • 8
  • 16
  • This is a pretty broad question with lots of smaller questions inside. The main questions are addressed in the one I've linked as duplicate. As for the others: please ask multiple separate and focused questions instead of one big question where you want to have everything covered. – Steffen Ullrich Feb 27 '20 at 14:11
  • I just want to get the basic idea. It is hard to by only mentioning a very small part – Tim Feb 27 '20 at 14:16
  • You are mixing questions about how the trust chain is verified in general with where parts are stored with if data are cached with curl specific stuff etc. This is more than "basic idea" but lots of specific questions which can actually be asked independently. – Steffen Ullrich Feb 27 '20 at 14:22
  • Yes, it is basic. Think about how one starts to learn about things that are unfamiliar or confusing. Don't use your current level of knowledge to measure others' – Tim Feb 27 '20 at 14:43

1 Answers1

1

Public keys of certificate authorities are stored locally for every applicatives on the system.

For example, on Debian GNU/Linux:

$ dpkg -l|grep -i ca-certificates
ii  ca-certificates                       20190110                        all          Common CA certificates
ii  ca-certificates-java                  20190909                        all          Common CA certificates (JKS keystore)

When you look at ca-certificates content:

$ dpkg -L ca-certificates|head -n30
/.
/etc
/etc/ca-certificates
/etc/ca-certificates/update.d
/etc/ssl
/etc/ssl/certs
/usr
/usr/sbin
/usr/sbin/update-ca-certificates
/usr/share
/usr/share/ca-certificates
/usr/share/ca-certificates/mozilla
/usr/share/ca-certificates/mozilla/ACCVRAIZ1.crt
/usr/share/ca-certificates/mozilla/AC_RAIZ_FNMT-RCM.crt
/usr/share/ca-certificates/mozilla/Actalis_Authentication_Root_CA.crt
/usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Commercial.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Networking.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Premium.crt
/usr/share/ca-certificates/mozilla/AffirmTrust_Premium_ECC.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_1.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_2.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_3.crt
/usr/share/ca-certificates/mozilla/Amazon_Root_CA_4.crt
/usr/share/ca-certificates/mozilla/Atos_TrustedRoot_2011.crt
/usr/share/ca-certificates/mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt
/usr/share/ca-certificates/mozilla/Baltimore_CyberTrust_Root.crt
/usr/share/ca-certificates/mozilla/Buypass_Class_2_Root_CA.crt
/usr/share/ca-certificates/mozilla/Buypass_Class_3_Root_CA.crt
/usr/share/ca-certificates/mozilla/CA_Disig_Root_R2.crt
[...]

Every single files contains a certificate, for example:

 cat /usr/share/ca-certificates/mozilla/Amazon_Root_CA_2.crt
-----BEGIN CERTIFICATE-----
MIIFQTCCAymgAwIBAgITBmyf0pY1hp8KD+WGePhbJruKNzANBgkqhkiG9w0BAQwF
ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
b24gUm9vdCBDQSAyMB4XDTE1MDUyNjAwMDAwMFoXDTQwMDUyNjAwMDAwMFowOTEL
MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
b3QgQ0EgMjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK2Wny2cSkxK
gXlRmeyKy2tgURO8TW0G/LAIjd0ZEGrHJgw12MBvIITplLGbhQPDW9tK6Mj4kHbZ
[...]
9jVlpNMKVv/1F2Rs76giJUmTtt8AF9pYfl3uxRuw0dFfIRDH+fO6AgonB8Xx1sfT
4PsJYGw=
-----END CERTIFICATE-----

The syntax you mentionned for Curl is if you want to override the system-wide certificates store to, for example, use your own certificate authority. It's called bundle because you may have several certificates involved in the signing process. For example: "Root CA" -- sign --> "Intermediate CA" -- sign --> Final certificate, so in this case, your bundle must contain both "Root CA" and "Intermediate CA" to succeed verifying the whole chain.

binarym
  • 784
  • 4
  • 8
  • Thanks. Are public keys of CAs and server certificates of servers stored separately? You answer seems to me that they are stored together in the same place? – Tim Feb 27 '20 at 13:44
  • Server certificates are retrieved by client during connection initiation and check against certificates authorities. Normally, they are not stored locally. The only thing you need to store locally is the whole chain of certificates that were used to sign server's one. Nevertheless, you may store server certificate if it was self-signed, to avoid browser complaint on every connection... – binarym Feb 27 '20 at 13:46
  • "The only thing you need to store locally is the whole chain of certificates that were used to sign server's one." What are these certificates? Are they related to the public keys of well known external CAs? Do clients need to store public keys of well known external CAs, or do they fetch the keys from the internet when needed? – Tim Feb 27 '20 at 14:09
  • "Are they related to the public keys of well known external CAs? " Yes. "Do clients need to store public keys of well known external CAs" Yes. "do they fetch the keys from the internet when needed?" No, cause how would client authenticate it ? ;-) – binarym Feb 27 '20 at 15:03
  • What is the relation between these certificates and the public keys of well known CAs? – Tim Feb 27 '20 at 15:06