Issues starting graylog 5 using GoDaddy wildcard SSL certificate on Ubuntu 22.04 LTS

1. Describe your incident:

Note that :// has been {obfuscated} to eliminate detection of extraneous links from config files and cer/key files.

Following the recipe described here: Enable HTTPS using existing certificates bought from GoDaddy - #2 by vneerukonda

We have used openssl to convert our wildcard key and cert and chain files to create a .pfx file, which we then used, following the above recipe, to create dedicated graylog.cer and graylog.key files. We ensured the files are owned by graylog:graylog in a sub-directory of /etc/graylog/ssl also owned by graylog:root

Used the recipe above, created the files, added the new cert to the cacerts.pks, updated the graylog java options file and still are getting the error:

com.github.joschi.jadconfig.ValidationException: Unreadable or missing HTTP X.509 certificate: null

2. Describe your environment:

  • OS Information: Ubuntu 22.04 LTS

  • Package Version: dpkg --list | grep graylog
    ii graylog-5.0-repository 1-2 all Package to install Graylog 5.0 GPG key and repository
    ii graylog-server 5.0.5-1 amd64 Graylog server

  • Service logs, configurations, and environment variables:
    /etc/graylog/server# grep -v “#” server.conf | grep -v ^$
    is_leader = true
    node_id_file = /etc/graylog/server/node-id
    password_secret ={obfuscated}
    root_username = admin
    root_password_sha2 ={obfuscated}
    root_email = “admin@{obfuscated}.{obfuscated}.org”
    root_timezone = US/Central
    bin_dir = /usr/share/graylog-server/bin
    data_dir = /var/lib/graylog-server
    plugin_dir = /usr/share/graylog-server/plugin
    http_bind_address = gl5log01.{obfuscated}.com:9000
    http_publish_uri = https{obfuscated}gl5log01.{obfuscated}.com:9000/
    http_external_uri = https{obfuscated}gl5log01.{obfuscated}.com:9000/
    http_enable_cors = true
    http_enable_tls = true
    http_tls_cert = /etc/graylog/ssl/graylog.cer
    http_tls_key_file = /etc/graylog/ssl/graylog.key
    elasticsearch_hosts = http{obfuscated}opensearch00:9200,http{obfuscated}opensearch01:9200,http{obfuscated}opensearch02:9200
    rotation_strategy = count
    elasticsearch_max_docs_per_index = 20000000
    elasticsearch_max_number_of_indices = 20
    retention_strategy = delete
    elasticsearch_shards = 4
    elasticsearch_replicas = 0
    elasticsearch_index_prefix = graylog
    allow_leading_wildcard_searches = false
    allow_highlighting = false
    elasticsearch_analyzer = standard
    output_batch_size = 500
    output_flush_interval = 1
    output_fault_count_threshold = 5
    output_fault_penalty_seconds = 30
    processbuffer_processors = 5
    outputbuffer_processors = 3
    processor_wait_strategy = blocking
    ring_size = 65536
    inputbuffer_ring_size = 65536
    inputbuffer_processors = 2
    inputbuffer_wait_strategy = blocking
    message_journal_enabled = true
    message_journal_dir = /var/lib/graylog-server/journal
    message_journal_max_size = 6gb
    lb_recognition_period_seconds = 3
    mongodb_uri = mongodb{obfuscated}glogdb01.{obfuscated}.com:27017,glogdb02.{obfuscated}.com:27017/graylog?replicaSet=MongoCluster
    mongodb_max_connections = 1000
    mongodb_version_probe_attempts = 5
    transport_email_enabled = true
    transport_email_hostname = smtp01.{obfuscated}.com
    transport_email_port = 25
    transport_email_use_auth = false
    transport_email_from_email = noreply@{obfuscated}.com
    enabled_tls_protocols = TLSv1.2,TLSv1.3
    skip_preflight_checks = false

Folder where cer and key reside:

/etc/graylog/ssl# ll
total 28
drwxr-xr-x 3 graylog root 4096 Mar 31 13:09 ./
drwxr-xr-x 4 root root 4096 Mar 30 10:46 …/
lrwxrwxrwx 1 root root 27 Jan 24 13:02 cacerts.jks → /etc/ssl/certs/java/cacerts
-rw------- 1 graylog graylog 2594 Mar 31 12:22 graylog.cer
-rw------- 1 graylog graylog 1832 Mar 31 12:23 graylog.key
drwxr-xr-x 4 root root 4096 Mar 31 13:09 old/
-rw------- 1 root root 6963 Mar 31 12:21 wildcard.{obfuscated}.com.pfx

Beginning of graylog.cer file:
:/etc/graylog/ssl# cat graylog.cer
Bag Attributes
localKeyID: AB FB 93 FD 5E 91 53 B3 78 06 37 F1 7A 0B 12 96 C8 CC 3A 08
subject=CN = *
issuer=C = US, ST = Arizona, L = Scottsdale, O = “GoDaddy {dot}com, Inc.”, OU = http{obfuscated} {dot} com/repository/, CN = Go Daddy Secure Certificate Authority - G2
{remainder deleted}

Contents of graylog.key file:
/etc/graylog/ssl# cat graylog.key
Bag Attributes
localKeyID: AB FB 93 FD 5E 91 53 B3 78 06 37 F1 7A 0B 12 96 C8 CC 3A 08
Key Attributes:
{remainder deleted}

3. What steps have you already taken to try and solve the problem?
Multiple paths and methods of converting apache, tomcat, iis versions of GoDaddy certificate files to formats that would be acceptable to Graylog.

Really not sure why the standard Tomcat version won’t simply work without conversions, but no method of converting using openssl has worked for us so far.

4. How can the community help?

We’ve found many places where folks are using self signed certs, but only a couple references to using a wildcard public signed cert from a recognized CA authority and only the .pfx version, which my provider, GoDaddy doesn’t provide, is even mentioned for an effective recipe for conversion.

Identify a pathway to take a standard certificate/key file from a national provider and make it work.

It would also be nice if the documentation links from inside Graylog would work for older versions instead of all generating a 404 error, but that’s a different issue…

We have an existing graylog4 deployment and are trying to build a new graylog5 with new backend storage using latest OSes and packages, this time enabling security as it is intended to be used by external departments and are finding it exceedingly difficult to get this working. It’s extremely frustrating to be trying seemingly random openssl conversion routines when documentation could share a recipe for use of one of the standard 3 formats of fully signed public certificates (apache, tomcat or even, iis).

Hey @dcalaf,

As per the docs “Both must to be stored in PEM format.”. Get the the cert and key converted to pem and you should be good.

To expand on what Wine_Merchant said:

Both public key and private key files must be in base64 pem format.

Public Cert

The public cert should contain all certs in the chain, with each cert starting with
and ending with

In context:


You can use something like Certificate Decoder - Decode certificates to view their contents to verify the text of each cert is free of errors.

Private Cert

The private key must start with

If the private key starts with
-----BEGIN PRIVATE KEY----- (unencrypted PKCS#8) or
you will need to convert the format of the certificate

openssl pkcs8 -in privkey.pem -topk8 -out privkey.pkcs8.pem

Java Key Store

This part is important as well and can be a bit tricky. The Adding a Self-Signed Certificate to the JVM Trust Store section should cover it but let us know if you have issues.

It sounds like you’ve already got the owner of the cert files set so thats good. Hope this helps. We are definitely aware certificate and TLS challenges both within the product and documentation and are working to improve! Feedback is always welcome so thank you for that.

OK… update…

We’ve re-converted the cert into a pem file with all three elements in it:





We also re-converted the key and tested it with a null passphrase as well as a passphrase:

less graylog-pkcs8-key.pem


One thing we found was that we somehow had lost the element ‘_file’ from the cert configuration element. The relavent tls config lines are now:

grep -v ‘#’ …/server/server.conf | grep tls
http_enable_tls = true
http_tls_cert_file = /etc/graylog/ssl/
http_tls_key_file = /etc/graylog/ssl/graylog-pkcs8-key.pem
http_tls_key_password = “{obfuscated}”
enabled_tls_protocols = TLSv1.2,TLSv1.3

We now see different info in the logs, but are still getting an error…

However, removing the quotes around my passphrase seems to have eliminated the errors showing up in server.log!!!

How on earth does a passphrase not need to be bracketed by quotes? Odd!!!

But I think it might be working…

1 Like

Great to know! I’m actually working on a comprehensive article about this topic, which included some of what i posted in my earlier reply. I’ll make sure to note this with the doublequotes. Thanks!

Having a step by step recipe for taking a standard SSL cert (regular or wildcard) in one of the usual formats (apache, tomcat or IIS) and each of the steps needed to bring it through to that needed by this crazy configuration would be ever so helpful.

At this point, due to losing the correct http_tls_cert_file configuration element (lost the _file part of the syntax) caused me to try so many different types of openssl translations.

Then there was the detour where following and trying the various base64 translations was a red herring.

Of course, it would be so much cleaner if the code was changed to simply accept tomcat style certificates :slight_smile:

ETA: Also, the parts of the various recipes that talk about adding keys to the java keystore were also irrelevant with a cert signed by a public signer who was already in the keystore. Absolutely needed for the use of self signed keys, sure… but a useless path to follow for use of ‘real’ certificates.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.