Failed to create new self-signed certificate

Icinga 2
, ,
1

Hi,

I have a bunch of cpanel server where I am trying to install the icinga2 agent. I have done this before using the director script without any issues. However on these servers where I have just taken over monitoring, it just fails without any log.

Trying to troubleshoot, I am doing it manually, but the node wizard fails the same place.

I am running this as root.

/home/etma ❯ icinga2 node wizard
Welcome to the Icinga 2 Setup Wizard!

We will guide you through all required configuration details.

Please specify if this is an agent/satellite setup (‘n’ installs a master setup) [Y/n]: y

Starting the Agent/Satellite setup routine…

Please specify the common name (CN) [server.localdomain]:

Please specify the parent endpoint(s) (master or satellite) where this node should connect to:
Master/Satellite Common Name (CN from your master/satellite node): [FQDN for server] (cannot input links because I am a new member)

Do you want to establish a connection to the parent node from this node? [Y/n]: y
Please specify the master/satellite connection information:
Master/Satellite endpoint host (IP address or FQDN): [FQDN for server]
Master/Satellite endpoint port [5665]:

Add more master/satellite endpoints? [y/N]: n
critical/cli: Failed to create new self-signed certificate for CN ‘server.localdomain’. Please try again.

I have also tried with a FQDN where the DNS points to this server. Same issue.
There are no logs being created anywhere, not in cwd, /var/logs/ or /var/logs/icinga2.

Can this be some missing dependencies that are not marked or maybe some wrong versions of a dependency?

This is the output of icinga2 --version

/home/etma ❯ icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: 2.11.0-1)

Copyright (c) 2012-2019 Icinga GmbH ([link omitted])
License GPLv2+: GNU GPL version 2 or later http://gnu.org/licenses/gpl2.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

System information:
Platform: CentOS Linux
Platform version: 7 (Core)
Kernel: Linux
Kernel version: 3.10.0-229.14.1.el7.centos.onapp.x86_64
Architecture: x86_64

Build information:
Compiler: GNU 4.8.5
Build host: runner-LTrJQZ9N-project-322-concurrent-0

Application information:

General paths:
Config directory: /etc/icinga2
Data directory: /var/lib/icinga2
Log directory: /var/log/icinga2
Cache directory: /var/cache/icinga2
Spool directory: /var/spool/icinga2
Run directory: /run/icinga2

Old paths (deprecated):
Installation root: /usr
Sysconf directory: /etc
Run directory (base): /run
Local state directory: /var

Internal paths:
Package data directory: /usr/share/icinga2
State path: /var/lib/icinga2/icinga2.state
Modified attributes path: /var/lib/icinga2/modified-attributes.conf
Objects path: /var/cache/icinga2/icinga2.debug
Vars path: /var/cache/icinga2/icinga2.vars
PID path: /run/icinga2/icinga2.pid

Please let me know if you need anything else in order to help.

2

Hmm… hard to say. I would check the existing certificates in /var/lib/icinga2/certs for the permissions and owner and check the permissions on that folder.

What if you try to create the certificates manually?

sudo icinga2 pki new-cert \ 
  --cn $(hostname) \
  --key /var/lib/icinga2/certs/$(hostname).key 
  --cert /var/lib/icinga2/certs/$(hostname).crt
3

Hi Marcel,

Thanks for your reply. Unfortunately, I had already tried that.

/home/etma ❯ sudo icinga2 pki new-cert --cn $(hostname) --key /var/lib/icinga2/certs/$(hostname).key --cert /var/lib/icinga2/certs/$(hostname).crt
information/base: Writing private key to ‘/var/lib/icinga2/certs/domain.key’.

/home/etma ❯ ls -la /var/lib/icinga2/certs
total 12
drwxr-x— 2 icinga icinga 4096 Oct 3 14:12 .
drwxr-x— 5 icinga icinga 4096 Oct 2 10:16 …
-rw------- 1 icinga icinga 3243 Oct 3 14:12 domain.key

As you can see, it did not write the .crt file.

However, I tried running “icinga2 console” which gave me an error that gdb was missing.
I installed it and the required debuginfo packages.

Now I have this error:

Error: getrandom

    (0) icinga2: icinga::ConsoleCommand::Run(boost::program_options::variables_map const&, std::vector<std::string, std::allocator<std::string> > const&) const (+0x6b) [0xafb89b]
    (1) /usr/lib64/icinga2/sbin/icinga2() [0xb30283]
    (2) icinga2: main (+0xb8) [0x5fff28]
    (3) libc.so.6: __libc_start_main (+0xf5) [0x7f21e0b59505]
    (4) /usr/lib64/icinga2/sbin/icinga2() [0x6029e3]

The full backtrace is here: https://pastebin.com/CEgBQC9A

It seems to be a bug in boost169?

4

Ah I see where you’re coming from with cPanel.

https://github.com/boostorg/uuid/issues/91#issuecomment-463197297 also sounds like as if RedHat would provide a possible backport.

In terms of the gdb notice - Icinga tries to write a crash log before everything is broken beyond repair. This includes running itself with gdb and generating a full backtrace for developers. Though this only happens when gdb as a debugger is installed on the system.