Reset web cert from ssh?

[VeeDubb65]

In the process of installing a cert from our active directory controller onto our 3300, I managed to somehow install a corrupted/broken cert.

As a result, I can't reach the admin tools or the server-manager web interfaces for the PBX at all. My only way to connect is through SSH.

Anybody know how to reset the certificates from the command line?

[VeeDubb65]

While digging around and trying the various things suggested by our VAR, I entered the following command while logged in via ssh:

service --status-all

That should be totally non-destructive and not hurt a thing.

However, it resulted in mountains of errors and a reboot.

Now the system will boot far enough for me to log in as root by SSH, but logging in as admin by SSH returns ADMIN LOGIN IS BLOCKED UNTIL MiVOICE BUSINESS IS STARTED and it's been like that for an hour and two reboots.

[VeeDubb65]

After a harrowing couple of hours, call control is back up for the PBX that went down hard.

Now I'm just back to the original issue of the corrupted cert.

[ZuluAlpha]

Is this an older version that you need to update the cert for syncing with the AMC?

[VeeDubb65]

Is this an older version that you need to update the cert for syncing with the AMC?

No, I'm actually running the latest patch roll-up, and the AMC is fine.

This is the website certificate. The server-manager for MSL allows you to upload your own certificate so you don't have to install the Mitel cert all over the place on your network, or make everyone who connects to the web interface for the PBX add an exception. I think very few places ever both, but using your own AD cert is much more secure than installing Mitel's generic cert all over the place.

[VeeDubb65]

Well, I fixed it today while waiting on a solution from our VAR and Mitel.

I won't post step-by-step since it's probably a one-in-a-million fluke to end up with a broken but fully installed cert, and if you're not comfortable enough on the linux command line and working with apache based web servers to get it from these details, you should probably get help form mitel and/or your VAR.

In any event, here are the parts that mattered:

-9.1 (and presumably 9.0 and future versions for a while) runs apache (or at least something that started life as apache).
-If you're used to working on linux web servers, be ready for everything to be in non-standard locations. If you're not used to working on linux/apache web servers, don't bother. Leave it to Mitel, and be prepared for them to say the best solution is to wipe the entire PBX and start with a fresh software load.
-'find' is your friend, although all the certs you uploaded will be not just renamed, but exported to different formats
-You can stop and start apache from the command line with"

Code: [Select]

service httpd-e-smith stop...and of course...

Code: [Select]

service httpd-e-smith start
Interestingly, the following command errors out, despite 'restart' being defined in the init scripts.

Code: [Select]

service httpd-e-smith restart
If you've installed your own cert, the cert is stored in the e-smith home directory (because who cares about standards?) at /home/e-smith/ssl.crt/thirdparty.cer and the key is stored under /home/e-smith/ssl.key/thirdparty.key

It should go without saying, that touching any of these files is probably not covered under your SWA, and you'll be looking at billable hours to fix any of this.

As a final word of warning, NEVER enter the following command:

Code: [Select]

service --status-all
On every linux server I've ever touched besides this mitel PBX, that command is utterly harmless, and simply lists the status of all configured services. On my 3300, it got a few services in, spewed a mile of unintelligible error messages, and then unexpectedly rebooted the PBX.  It took multiple reboots, a second attempt at running that command to see if it was a fluke (it was not a fluke) and ultimately letting the system sit after reboot for more than an hour before call controll came back up.