You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the CN will always be the 'default' ip-based CN, but some client certificate auth schemes use only CN to authenticate (namely: http://floragunncom.github.io/search-guard-docs/tls_certificates_production.html). To facilitate glob matching like: *.subdomain.namespace.svc.cluster.local on CN, I would suggest having a flag that switches the array places of the headless service hostname and the pod ip hostname. Will submit PR soon.
The text was updated successfully, but these errors were encountered:
mikn
linked a pull request
Nov 29, 2017
that will
close
this issue
Right now the CN will always be the 'default' ip-based CN, but some client certificate auth schemes use only CN to authenticate (namely: http://floragunncom.github.io/search-guard-docs/tls_certificates_production.html). To facilitate glob matching like:
*.subdomain.namespace.svc.cluster.local
on CN, I would suggest having a flag that switches the array places of the headless service hostname and the pod ip hostname. Will submit PR soon.The text was updated successfully, but these errors were encountered: