tokers commented on code in PR #8915:
URL: https://github.com/apache/apisix/pull/8915#discussion_r1119492247
##########
docs/en/latest/FAQ.md:
##########
@@ -704,6 +704,14 @@ Another solution is to switch to an experimental
gRPC-based configuration synchr
prefix: "/apisix"
```
+## What is the difference between SSLS and tls.client_cert in upstream
configurations, and ssl_trusted_certificate in config-default.yaml?
Review Comment:
Use `SSLs` instead of `SSLS`.
##########
docs/en/latest/FAQ.md:
##########
@@ -704,6 +704,14 @@ Another solution is to switch to an experimental
gRPC-based configuration synchr
prefix: "/apisix"
```
+## What is the difference between SSLS and tls.client_cert in upstream
configurations, and ssl_trusted_certificate in config-default.yaml?
+
+The `ssls` is managed through the `/apisix/admin/ssls` API. If APISIX needs to
receive HTTPS requests from the Internet, the certificate stored here is used
for handshake. Multiple certificates can be configured in SSLS, and APISIX uses
Server Name Indication (SNI) to differentiate between certificates of different
domains.
Review Comment:
```suggestion
The `ssls` is managed through the `/apisix/admin/ssls` API. It's used for
managing TLS certificates. These certificates may be used during TLS handshake
(between Apache APISIX and its clients). Apache APISIX uses Server Name
Indication (SNI) to differentiate between certificates of different domains.
```
##########
docs/en/latest/FAQ.md:
##########
@@ -704,6 +704,14 @@ Another solution is to switch to an experimental
gRPC-based configuration synchr
prefix: "/apisix"
```
+## What is the difference between SSLS and tls.client_cert in upstream
configurations, and ssl_trusted_certificate in config-default.yaml?
+
+The `ssls` is managed through the `/apisix/admin/ssls` API. If APISIX needs to
receive HTTPS requests from the Internet, the certificate stored here is used
for handshake. Multiple certificates can be configured in SSLS, and APISIX uses
Server Name Indication (SNI) to differentiate between certificates of different
domains.
+
+The `tls.client_cert`, `tls.client_key`, and `tls.client_cert_id` in upstream
are actually certificates for the client, used in cases where mTLS
communication is required with the upstream.
+
+The `ssl_trusted_certificate` in config-default.yaml configures a trusted root
certificate. It is only used for accessing services with self-signed
certificates (such as Keycloak) within APISIX, to avoid prompting that the
certificate of the other party is invalid. Note that it is not used to trust
the certificates of APISIX upstream, because APISIX does not verify the
legality of the upstream certificates. Therefore, even if the upstream uses an
invalid TLS certificate, it can still be accessed without configuring a root
certificate.
Review Comment:
1. It's not a root certificate, it's a CA certificate.
2. It's not used **only** for self-signed certificates, but for verifying
some certificates signed by private authorities.
##########
docs/en/latest/FAQ.md:
##########
@@ -704,6 +704,14 @@ Another solution is to switch to an experimental
gRPC-based configuration synchr
prefix: "/apisix"
```
+## What is the difference between SSLS and tls.client_cert in upstream
configurations, and ssl_trusted_certificate in config-default.yaml?
+
+The `ssls` is managed through the `/apisix/admin/ssls` API. If APISIX needs to
receive HTTPS requests from the Internet, the certificate stored here is used
for handshake. Multiple certificates can be configured in SSLS, and APISIX uses
Server Name Indication (SNI) to differentiate between certificates of different
domains.
+
+The `tls.client_cert`, `tls.client_key`, and `tls.client_cert_id` in upstream
are actually certificates for the client, used in cases where mTLS
communication is required with the upstream.
Review Comment:
```suggestion
The `tls.client_cert`, `tls.client_key`, and `tls.client_cert_id` in
upstream are used for mTLS communication with the upstream.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
