[BlueOnyx:20053] Re: 5208R, stop replacing my cert

Michael Stauber mstauber at blueonyx.it
Wed Aug 31 18:48:50 -05 2016


Hi Chris,

> Since it was a wildcard cert, the CSR was initiated from command line.
> The installation of the cert and the CA was performed via GUI.

I see. Many thanks for getting back to me on that.

I just checked the code that's responsible for the generation of the
AdmServ certificate. It's this constructor:

/usr/sausalito/constructor/base/ssl/gen_adm_cert.pl

Before it does anything at all it has these lines of code in it:

if (-e '/etc/admserv/certs/certificate') {
	exit(0);
}

So if /etc/admserv/certs/certificate exists, the script will exit
without doing anything. If /etc/admserv/certs/certificate is missing,
it'll create the self signed certificate for AdmServ.

So far, so good. So what caused it? That had me puzzled, until I found a
5207R of mine where this had happened this morning as well. That box had
a "Let's Encrypt" cert installed for AdmServ and it got replaced with a
self signed one.

I checked /var/log/cron and could see no cronjob related to that. But
/var/log/messages tells the story:

----------------------------
Aug 31 06:02:02 5207r yum[26476]: Updated:
base-user-ui-2.0.0-0BX19.bx.noarch
Aug 31 06:02:06 5207r yum[26476]: Updated:
base-user-glue-2.0.0-0BX19.bx.noarch
Aug 31 06:02:06 5207r yum[26476]: Updated:
base-user-locale-fr_FR-2.0.0-0BX19.bx.noarch
Aug 31 06:02:06 5207r yum[26476]: Updated:
base-user-locale-da_DK-2.0.0-0BX19.bx.noarch
Aug 31 06:02:07 5207r yum[26476]: Updated:
base-user-locale-it_IT-2.0.0-0BX19.bx.noarch
Aug 31 06:02:07 5207r yum[26476]: Updated:
base-user-locale-en_US-2.0.0-0BX19.bx.noarch
Aug 31 06:02:08 5207r yum[26476]: Updated:
base-user-locale-de_DE-2.0.0-0BX19.bx.noarch
Aug 31 06:02:08 5207r yum[26476]: Updated:
base-user-locale-es_ES-2.0.0-0BX19.bx.noarch
Aug 31 06:02:08 5207r yum[26476]: Updated:
base-user-locale-ja_JP-2.0.0-0BX19.bx.noarch
Aug 31 06:02:08 5207r yum[26476]: Updated:
base-user-locale-nl_NL-2.0.0-0BX19.bx.noarch
Aug 31 06:02:08 5207r yum[26476]: Updated:
base-user-locale-pt_PT-2.0.0-0BX19.bx.noarch
Aug 31 06:02:11 5207r yum[26476]: Updated:
base-user-capstone-2.0.0-0BX19.bx.noarch
Aug 31 06:02:17 5207r cced(smd)[26588]: client [0:26587] has admin rights
Aug 31 06:02:17 5207r cced(smd)[24565]: caught SIGTERM: cleaning up
Aug 31 06:02:17 5207r cced(smd)[24565]: exiting
Aug 31 06:02:18 5207r cced[26616]: Cobalt Configuration Engine (CCE)
version 0.99.2
Aug 31 06:02:18 5207r cced[26616]: Copyright (c) 1999,2000 Cobalt
Networks, Inc. - Copyright (c) 2014 Team BlueOnyx, BLUEONYX.IT
Aug 31 06:02:18 5207r cced[26616]: starting up (pid 26616)
Aug 31 06:02:18 5207r root: cce_construct started
Aug 31 06:02:18 5207r root: ***** cce_construct:
/usr/sausalito/constructor/base/system/10_addSystem.pl
Aug 31 06:02:25 5207r cced(smd)[26622]: client [0:26621] has admin rights
Aug 31 06:02:25 5207r cced(smd)[26622]: client 0:[0:26621]: SET  1 dns =
"&208.67.251.180&208.77.221.199&8.8.8.8&4.2.2.2&208.67.251.180&208.77.221.199&8.8.8.8&4.2.2.2&208.67.251.180&208.77.221.199&8.8.8.8&4.2.2.2&208.67.251.180&208.77.221.199&8.8.8.8&4.2.2.2&"
locales = "&en_US&da_DK&de_DE&es_ES&fr_FR&it_IT&ja_JP&nl_NL&pt_PT&"
console = 0 domainname = "smd.net" hostname = 5207r productIdentity =
20140909 productBuild = 5207R productLanguage = en_US productBuildString
= "build 20140909 for a 5207R in en_US"
Aug 31 06:02:44 5207r cced(smd)[26622]: client
0:handlers/base/dns/dns_generate.pl: SET  1 . DNS dirty = 0
Aug 31 06:02:44 5207r cced(smd)[26622]: client
0:handlers/base/dns/dns_generate.pl: SET succeeded
Aug 31 06:02:46 5207r cced(smd)[26622]: client
0:handlers/base/ssl/ssl.pl: SET  1 . SSL expires = "Aug 31 2017 11:02:46
GMT"
Aug 31 06:02:46 5207r cced(smd)[26622]: client
0:handlers/base/ssl/ssl.pl: SET succeeded
----------------------------

At 6:00 the daily "yum update" did run and it did install some updates.
Now the updates weren't the problem. It was the CCEd restart that the
updates triggered.

That ran /usr/sausalito/constructor/base/system/10_addSystem.pl, which
updated the "System" object with things like which DNS servers we use,
system hostname, locale and such.

But that triggered this:

handlers/base/ssl/ssl.pl: SET  1.SSL expires="Aug 31 2017 11:02:46 GMT"
handlers/base/ssl/ssl.pl: SET succeeded

There you can see that the handler ssl/ssl.pl did run and it set a new
expiry date for the SSL certificate. It would only do so if it has
generated a new SSL certificate. Which it did!

Why did it generate a new SSL cert? Because the host- or domainname of
the server may have changed. There are these freak cases where BlueOnyx
servers revert their hostname back to something that was configured ages
ago.

I don't have a clue what might trigger the host-/domainname flip-flop,
but it might be responsible for this.

I will overhaul the handler ssl/ssl.pl to not overwrite AdmServ
certificates that are not self signed. That should solve this problem
until we can tackle the rare hostname flip-flop.

-- 
With best regards

Michael Stauber



More information about the Blueonyx mailing list