Skip to content

Commit

Permalink
fix linting
Browse files Browse the repository at this point in the history
  • Loading branch information
gruceo committed Aug 26, 2024
1 parent 6fea35b commit 8af4f2b
Show file tree
Hide file tree
Showing 2 changed files with 3 additions and 3 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -47,4 +47,4 @@ The `id` value returned can now be used for the header-cert-auth plugin configur
{:.important}
> **Important:** To ensure proper certificate validation, it is important to upload all required Certificate Authorities (CAs) and their intermediates into the Kong CA store.
<br><br>
> Failure to do so may result in incomplete certificate validation, as some WAFs and load balancer providers only send the end-leaf certificate in their header, rather than encoding the entire certificate chain sent by the client. This is especially crucial when using the `base64_encoded` format.
> Failure to do so may result in incomplete certificate validation, as some WAF and load balancer providers only send the end-leaf certificate in their header, rather than encoding the entire certificate chain sent by the client. This is especially crucial when using the `base64_encoded` format.
4 changes: 2 additions & 2 deletions app/_hub/kong-inc/header-cert-auth/overview/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,15 +27,15 @@ requested route or service:
The plugin can be configured to only accept certificates from trusted IP addresses, as specified by the [`trusted_ips`](/gateway/{{page.release}}/reference/configuration/#trusted_ips) config option. This ensures that Kong can trust the header sent from the source and provides L4 level of security.

{:.important}
> **Important:** Misconfiguring or misusing the Header Cert Authentication plugin can compromise the security of your API.
> **Important:** Misconfiguration of the Header Cert Authentication plugin can compromise the security of your API.

Check failure on line 30 in app/_hub/kong-inc/header-cert-auth/overview/_index.md

View workflow job for this annotation

GitHub Actions / Vale

[vale] reported by reviewdog 🐶 [kong.Spelling] Did you really mean 'Misconfiguration'? Raw Output: {"message": "[kong.Spelling] Did you really mean 'Misconfiguration'?", "location": {"path": "app/_hub/kong-inc/header-cert-auth/overview/_index.md", "range": {"start": {"line": 30, "column": 18}}}, "severity": "ERROR"}
<br><br>
> For instance, enabling the option to bypass origin verification can allow malicious actors to inject fake certificates, as Kong will not be able to verify the authenticity of the header. This can downgrade the security level of the plugin, making your API vulnerable to attacks. Ensure you carefully evaluate and configure the plugin according to your specific use case and security requirements.
Additionally, the plugin has a [static priority](/konnect/reference/plugins/) configured so that it runs after all authentication plugins, allowing other auth plugins (e.g. basic-auth) to secure the source first. This ensures that the source is secured by multiple layers of authentication by providing L7 level of security.

### Client certificate request

Send_ca_dn is not supported in this plugin. This is used in mutual TLS authentication, where the server sends the list of trusted CAs to the client, and the client then uses this list to select the appropriate certificate to present. In this case since the plugin does not do TLS handshakes and only parses the client certificate from the header, it is not applicable.
The `send_ca_dn` option is not supported in this plugin. This is used in mutual TLS authentication, where the server sends the list of trusted CAs to the client, and the client then uses this list to select the appropriate certificate to present. In this case since the plugin does not do TLS handshakes and only parses the client certificate from the header, it is not applicable.

The same applies to SNI functionality. The plugin can verify the certificate without needing to know the specific hostname or domain being accessed. The plugin's authentication logic is decoupled from the TLS handshake and SNI, so it doesn't need to rely on SNI to function correctly (pretty much anything that deals with the actual TLS handshake is not needed for the plugin to work).

Expand Down

0 comments on commit 8af4f2b

Please sign in to comment.