NSFAQ (Not So Frequently Asked Questions)

It seems the usual procedure for renewing HTTPS certificates for IIS is starting a renewal request, sending it to de CA (Verisign, for example), wait for a file in the reply and import it inside your IIS.

But, what can we do if we have the renewal certificate with a former CSR? You get an e-mail with a part like this:

How can we import this inside our IIS? We should follow this steps:

First we export the current certifical. In order to do this, we should go to site properties, tab "Directory Security":

We start the wizard clicking on "Server Certificate" and go to next screen:

We click on "Next" and go to the next screen:

Where we will choose "Export the current certificate to a .pfx file". After that, we will be asked where to put it:

And a password for the export. This way we have our certificate exported.

If we look inside the file, we will see it is binary. To convert it to the same format we received on the email, we can use openssl, with this command:

It will ask us for the password we've put before, and will ask for another password to put to the .pem resulting file.
If we edit this file with any text editor, we will see it contains a "certificate" part, delimited by "BEGIN CERTIFICATE" and "END CERTIFICATE" clauses, exactly the same as the part we got on the email. We just should change the former certificate text with the new one. Once we have done this, we can put it again to binary, "understandable" by IIS. In order to do this, we use again openssl:

It will ask us for the .pem password, and another password to put to the resulting .pfx. Now, to put it in the IIS site, first we shoult take out the former certificate. In "Directory Security" tab we should start the wizard again, but this time we will choose "Remove the current certificate":

Clicking "next next" we will take out former certificate:

Now we should import the new certificate. In the wizard we will see a new option: "Import certificate from a .pfx file":

It will ask us for the file to import, and we should choose cert-new.pfx. It will ask us for the password, the port to listen (usually we will use the default 443) and finally we will have the certificate imported:

If we look at certificate properties, we will see expiration date has changed. We have the certificate renewed!

I just found out, since debian lenny, and in Ubuntu/KUbuntu (I don't know if it was in 8.04, but it do is in 8.10), winexe application, of which we talked about and used, for instance, in our process killing scripts or remote shell scripts, comes with wmi-client package. That is, if you want to install it, you just should do:

And done! I guess RedHat and Suse have this package too... can anyone confirm this?

Following the path we were on former posts , if we have seed with psexec, noe it's very easy to make new tools. Three examples:

winshell.sh
With this tool we get a shell in windows servers. It doesn't use psexec because it haven't, cmd.exe is in system path.

wininfo.sh
With this tool we can get some server information. Physical RAM, SO version, uptime, number of processos, frequency of them, and video card driver. This last detail doesn't seems important at all, but it's very useful, because it can tell you wether if a server is physical or virtual. If video driver is something like "ATI Technologies Inc. 3D RAGE IIC PCI", then it's a physical machine. If video driver is something like"VMware SVGA II", then it's a virtual machine.

winkill.sh
As its name clearly stands, it's a process killing tool (we can previously know the PID useing winps.sh).

If we want to check the event log of a windows server from our linux console (without having to connect through terminal server, allowing us to grep the results, etc, etc, etc), here we have the tool!

We use psloglist with this parameters:
-d 1 so it shows just last day of logs (we don't want to be flooded with logs)
-f we so just warning and errors will be shown (usually, only those are interesting)
$2 this is the second parameter. If we wnat to see just "application" or "system" logs (usually the only interesting) you just type it there.

Next mission was making scripts to execute pstools remotely. I started make one for each tool, but I found out there was a lot of shared code, so I decided to create an generic script, psexec.sh (honoring pstools), receiving the server and the tool, with its parameters. After that, we should only create a wrapper for every command to make our life easier.

The script must check if file credentials are valid, and asking for others if they aren't. Once authenticated, it must check if there's pstools installed or not, and copy them if not.

In the full story you can see the code of psexec.sh and an example wrapper, winps.sh. Keep in mind that they need some files, winvars.sh and cp_pstools.sh in order to work properly, as we saw in the previous post.

Following the path we were... What if we want to use pstools in 50 servers? As an idea, we can creat a shared unit, and make all servers to execute pstools there. But if we have some in some networks, some in some other networks (including DMZ), in a domain or not... Couln't be an easy way to copy them?

With this purpose I've made this little script, doing exactly that: copying pstools to the server we want. First of all it mounts a cifs unit (with smbmount), then copy the files and then umount it.

I've made it to be called from other scripts. For instance, if we make a "winps", we can make it to check if pstools are installed first, and to copy them if they aren't.

In the full article you can see the code an download the file.

You are trying to connect via remote desktop (terminal server) to the server, but you find out there's too much people already connected. You get the damn message:

What can I do? Is easy. As we already have our brand new tool winexe, we can make a little script to make our lives easier:

File "secretfile" is optional, just in case you don't want to type user and pass. Contents are:

That's an poorly error-controlled script, but it allows you to watch who is connected:

In this server you can't login, there are too much users. We can see everybody is "disconnected", so there is no one working. We choose the user we like the least, and we kick him out:

Et voilà, we just get a free session to connect to admin this server.

Obviously, is way better if everybody logs off when they end working. But if you have to share your servers with absentminded admins, you must take care of yourself...

When you see a windows stopped server in your nagios console, sometimes you would like to add an event_handler who tries to start the service automatically.

With samba , it´s been a long term feature, some way to control services ( net stop or net start ), but I haven't found that this ever worked.

There's a useful tool: winexe . With this tool, you can, not only stop and start windows services, but execute any shell comand, even having a windows shell inside your linux box, as simply as:

In the previous post, where we talked about winexe, we showed how to execute shell commands from our linux console. Our first idea was to start and stop services ( net start; net stop), but once we have a windows shell, we can go beyond a do a lot more. to achieve that, we can use pstools .

I've found that executing pstools directly from the console, without gui (in my case, using winexe ), it got stuck, sort of hung. Trying to connect via remote desktop to the server, and executing then by hand, it shows a window with an EULA, waiting for our "Ok, I agree".