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 _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx