[BUG] Custom branding fails for SSL enabled because certs aren't passed in the verification

[awuetz]

Describe the bug

We did setup the opensearch-dashboards as docker container and did configure the custom branding according to the documentation

opensearchDashboards.branding:
  logo:
    defaultUrl: "https://<SERVERNAME>:5601/ui/icon.svg"
    darkModeUrl: "https://<SERVERNAME>:5601/ui/icon.svg"
#  loadingLogo:
#    defaultUrl: ""
#    darkModeUrl: ""
#  mark:
#    defaultUrl: ""
#    darkModeUrl: ""
#  faviconUrl: ""
  applicationTitle: "Loggingsystem"

The applicationTitle setting is working, but the rest of the URLs are not working, we still see the default opensearch logo/icons.
Doing a curl is valid if I pass the "-k" parameter to omit the certificate validation.

In the logfile I see messages like:

{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"logo default config is not found or invalid"}
{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"mark default config is not found or invalid."}
{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"loadingLogo default config is not found or invalid."}
{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"favicon config is not found or invalid."}

Expected behavior
The configured icons should be shown in frontend.

OpenSearch Version
Docker Image: opensearchproject/opensearch:1.2.3

Dashboards Version
Docker Image: opensearchproject/opensearch-dashboards:1.2.0

Plugins

Please list all plugins currently enabled.
opensearch-alerting
opensearch-anomaly-detection
opensearch-asynchronous-search
opensearch-cross-cluster-replication
opensearch-index-management
opensearch-job-scheduler
opensearch-knn
opensearch-observability
opensearch-performance-analyzer
opensearch-reports-scheduler
opensearch-security
opensearch-sql

[kavilla]

Hello @awuetz,

Thanks for opening this! Just to verify when the server is running, you can navigate to https://<SERVERNAME>:5601/ui/icon.svg and see your logo?

{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"logo default config is not found or invalid"}
{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"mark default config is not found or invalid."}
{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"loadingLogo default config is not found or invalid."}
{"type":"log","@timestamp":"2022-01-19T12:30:54Z","tags":["info","branding"],"pid":1,"message":"favicon config is not found or invalid."}

Based on the logs it might not actually be able to see that. Are you dumping your assets into the docker container every time you are start it since putting stuff in the assets folder is a workaround solution for having your own server hosted or having some CDN until there is an improvement to start a server not tracked in source control. But if you are using docker images, every time the server starts it will wipe out this temp solution unless you have something specifically taking a file and putting it in that folder.

You can ignore the other log messages about configs you haven't set, we have improvement not to log configs not set everytime you start or refresh the application. PR: #941

Also, unfortunately the custom branding configuration is only consumed from the base OpenSearch Dashboards. So plugins like the security plugin (the login screen) do not consume the configuration yet. Perhaps we can make an issue in that repo to do so since the logic is built out to be consumed by plugins.

Finally:

  logo:
    defaultUrl: "https://<SERVERNAME>:5601/ui/icon.svg"
    darkModeUrl: "https://<SERVERNAME>:5601/ui/icon.svg"

This logo is only consumed by the header bar. I'd recommend using mark, mark is used through out the base OpenSearch Dashboards. If you don't set logo, it will default use mark in the header menu but we provided a logo which intended to give a wider option for the header bar.

Let me know if need me to clarify anything.

[awuetz]

Hi @kavilla

i do see these log messages after the startup of the container, as soon as a user accesses the dashboard:

opensearch-dashboard  | {"type":"log","@timestamp":"2022-01-20T07:16:46Z","tags":["listening","info"],"pid":1,"message":"Server running at https://0.0.0.0:5601"}
opensearch-dashboard  | {"type":"log","@timestamp":"2022-01-20T07:16:46Z","tags":["info","http","server","OpenSearchDashboards"],"pid":1,"message":"http server running at https://0.0.0.0:5601"}
opensearch-dashboard  | {"type":"log","@timestamp":"2022-01-20T07:17:09Z","tags":["info","branding"],"pid":1,"message":"logo default config is not found or invalid"}
opensearch-dashboard  | {"type":"log","@timestamp":"2022-01-20T07:17:09Z","tags":["info","branding"],"pid":1,"message":"mark default config is not found or invalid."}
opensearch-dashboard  | {"type":"log","@timestamp":"2022-01-20T07:17:09Z","tags":["info","branding"],"pid":1,"message":"loadingLogo default config is not found or invalid."}
opensearch-dashboard  | {"type":"log","@timestamp":"2022-01-20T07:17:09Z","tags":["info","branding"],"pid":1,"message":"favicon config is not found or invalid."}

"Are you dumping your assets into the docker container", yes we are using docker compose here and we ensured, that the files are present within the container. Also the owner of the files is the user and group opensearch-dashboards and it is readable.

I already tested with all options, so I do see the same behavior for all of those branding urls. The mark was now additionally enabled.

opensearchDashboards.branding:
  mark:
    defaultUrl: https://<SERVERNAME FQDN>:5601/ui/fav32.png
    darkModeUrl: ""

What I also noticed was, that I do not see my configured URLs neither in the logs nor if I observe the browser requests.
The logs still show these kind of request logs:

opensearch-dashboard  | {"type":"response","@timestamp":"2022-01-20T07:26:09Z","tags":[],"pid":1,"method":"get","statusCode":200,"req":{"url":"/ui/default_branding/opensearch_mark_default_mode.svg","method":"get","headers":{"host":"<SERVERNAME FQDN>:5601","user-agent":"Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0","accept":"image/avif,image/webp,*/*","accept-language":"de,en-US;q=0.7,en;q=0.3","accept-encoding":"gzip, deflate, br","connection":"keep-alive","referer":"https://<SERVERNAME FQDN>:5601/app/management/opensearch-dashboards/indexPatterns?bannerMessage=To%20visualize%20and%20explore%20data%20in%20OpenSearch%20Dashboards,%20you%20must%20create%20an%20index%20pattern%20to%20retrieve%20data%20from%20OpenSearch.","sec-fetch-dest":"image","sec-fetch-mode":"no-cors","sec-fetch-site":"same-origin","pragma":"no-cache","cache-control":"no-cache"},"remoteAddress":"53.55.134.124","userAgent":"Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0","referer":"https://<SERVERNAME FQDN>:5601/app/management/opensearch-dashboards/indexPatterns?bannerMessage=To%20visualize%20and%20explore%20data%20in%20OpenSearch%20Dashboards,%20you%20must%20create%20an%20index%20pattern%20to%20retrieve%20data%20from%20OpenSearch."},"res":{"statusCode":200,"responseTime":9,"contentLength":9},"message":"GET /ui/default_branding/opensearch_mark_default_mode.svg 200 9ms - 9.0B"}

So I was wondering if the branding config is working at all?

[kavilla]

"Are you dumping your assets into the docker container", yes we are using docker compose here and we ensured, that the files are present within the container. Also the owner of the files is the user and group opensearch-dashboards and it is readable.

Would you be willing to share you docker-compose file? If not, no worries!

As of the current release, custom branding requires something to be serving these files. Sorry for the redundancy, but if you don't have something externally serving these images then the docs only provide a temp workaround. Any files that are placed in src/core/server/core_app/assets will be served up under https://<SERVERNAME>:5601/ui/. For example, if I have a logo called pizza.svg I would have to make sure that in my Docker container for OpenSearch Dashboards would have src/core/server/core_app/assets/pizza.svg. Then when OpenSearch Dashboards successfully starts, it will host pizza.svg like the following https://<SERVERNAME>:5601/ui/pizza.svg.

So just to verify you have a docker-compose file that adding the file to the nested assets folder and it is still having issues accessing the file?

So I was wondering if the branding config is working at all?

I think it should be since the applicationTitle is coming through correct? There is just some verification on the URLs provide that the file returned doesn't 404. So if it doesn't 404 it will use the default branding configurations.

If it turns out that it wasn't added to the assets folder, then I think we should use this issue #1022 to make it less complicated since I do believe relying a nested folder is really confusing.

Let me know! Thank you so much!

[awuetz]

@kavilla yes i choose to use the temp workaround.

  opensearch-dashboard:
[....]
    ports:
      - 5601:5601
    expose:
      - "5601"
[....]
    volumes:
[...]
      - /opt/sc/elk/opensearch-dashboards/config/fav32.png:/usr/share/opensearch-dashboards/src/core/server/core_app/assets/fav32.png:ro
      - /opt/sc/elk/opensearch-dashboards/config/icon.svg:/usr/share/opensearch-dashboards/src/core/server/core_app/assets/icon.svg:ro

I have already validated, that the fav32.png and icon.svg are existing in the container in path /usr/share/opensearch-dashboards/src/core/server/core_app/assets and I am able to access my custom assets via https://<SERVERNAME FQDN>:5601/ui/icon.svg
So from this side everything is looking fine.

Regarding the URL validation: "here is just some verification on the URLs provide that the file returned doesn't 404", could it be an issue due to the fact, that we have TLS enabled server.ssl.enabled: true?
So to download the file with curl I have to provide a valid ca certificate or to disable certificate validation (with param -k / --insecure)

[saegel]

I have the same exact issue.
If I disable SSL, the custom branding works but when I enable SSL using my self-signed certificates, it stops working.

[kavilla]

@saegel and @awuetz, thanks for catching this bug! The validation isn't passing the certificates and this will need to be fixed.

Will change the title of this bug!

[kavilla]

Duplicate issue: #1243

[jkrishnarao2003]

We are using OpenSearch 2.0.0 version but still facing custom logo over HTTPs. Any update on any fix for this issue?
We are seeing errors like this Dashboard logs and default logos are loaded.

{"type":"log","@timestamp":"2022-07-21T12:58:52Z","tags":["error","branding"],"pid":23552,"message":"logo default URL was not found or invalid. Using default branding."}
{"type":"log","@timestamp":"2022-07-21T12:58:52Z","tags":["error","branding"],"pid":23552,"message":"mark default URL was not found or invalid. Using default branding."}
{"type":"log","@timestamp":"2022-07-21T12:58:52Z","tags":["error","branding"],"pid":23552,"message":"loadingLogo default URL was not found or invalid. Using default branding."}
{"type":"log","@timestamp":"2022-07-21T12:58:52Z","tags":["error","branding"],"pid":23552,"message":"favicon URL was not found or invalid. Using default branding."}

[kavilla]

Hello @jkrishnarao2003,

Do you mind sharing your opensearch_dashboards.yml config? A few things that I can think of that might still be preventing you from using this. Other folks start the server with their the certs then they do some actions on the certs to prevent it from being readable after the application is running per their requirements. The validation happens every time the application is rendered so if the certs are not valid at runtime then the logo won't load.

[jkrishnarao2003]

Sure. this opensearch_dashboards.yml config works only with http but not with https. Modified some confidential details.

opensearch.hosts: [<hosts>]
#self signed ones
opensearch.ssl.certificateAuthorities: ["/<path>/root-cert.pem"]
opensearch.ssl.verificationMode: certificate
opensearch.username: kibanaserver
opensearch.password: kibanaserver
opensearch.requestHeadersWhitelist: [authorization, securitytenant]

server.host: 0.0.0.0
server.port: <port>
server.name: '<name>'

opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.enable_private: true
opensearch_security.multitenancy.tenants.enable_global: true
opensearch_security.multitenancy.enable_filter: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.readonly_mode.roles: [kibana_read_only]
opensearch_security.cookie.secure: false

console.enabled: false
data.search.usageTelemetry.enabled: true

server.rewriteBasePath: true
server.basePath: /<sub-path>

opensearchDashboards.branding:
  logo:
    defaultUrl: "https://<site.com>/<sub-path>/ui/assets/my-logo.svg"
  mark:
    defaultUrl: "https://<site.com>/<sub-path>/ui/assets/my-logo.svg"
  loadingLogo:
    defaultUrl: "https://<site.com>/<sub-path>/ui/assets/my-logo.svg"
  faviconUrl: "https://<site.com>/<sub-path>/ui/assets/my-logo.svg"
  applicationTitle: "<Title>"


opensearch_security.auth.type: "saml"
server.xsrf.whitelist: ["/_plugins/_security/saml/acs/idpinitiated", "/_plugins/_security/saml/acs", "/_plugins/_security/saml/logout","/_opendistro/_security/saml/acs/idpinitiated", "/_opendistro/_security/saml/acs", "/_opendistro/_security/saml/logout"]

[jkrishnarao2003]

Thanks for reviewing.

[bbarani]

@joshuarrrr @kavilla Please tag this issue to the correct version.

[harsh1802]

Hello @joshuarrrr @kavilla ,
Do we have any workaround for this? or is it possible to achieve this via custom plugin? If yes, then can you please help me out how to acheive this?