Signed certificate on the IBM IMM2

Yes, I know the pictures look silly and sticking out. Frankly, my dear, I don't give a damn.
The IBM ILO, the IMM (Integrated Management Module) v.2 supports signed certificates for it's https web UI. The get it, you will have to generate a CSR on it, then sign it off and upload the signed cert file back to the IMM2.
Now, this is not a big deal, but as IBM mentions, this only works with DER format.
The whole process, step-by-step:

• Go to the IMM Management menu on the UI, and select Security.
• Here, choose Generate a New Key and a Certificate Signing Request (CSR)
• When it's done, choose Download Certificate Signing Request (CSR) and download the file.

• Now, let's display it's contents: openssl req -in imm2.csr -inform DER -text -noout
• It should display the request, thus the CSR is in DER format. OpenSSL likes PEM better...
• Now, convert the DER file into PEM: openssl req -in imm2.csr -inform DER -out imm2-pem.csr
• It is now possilbe to sign the CSR: openssl x509 -req -in imm2-pem.csr -CA myroot.crt -CAkey rui.key -CAcreateserial -out imm2-der.crt -days 3650 -outform DER note the -outform DER parameter in the end, IMM2 requires a DER format signed certificate to be uploaded!
• You can now simply upload the file, choose Import a Signed Certificate to browse for it
• Restarting IMM2 or it's https service will make use of the new certificate now!

vCloud Director 5.1.1 properly signed certificates - step-by-step

First, have an own root certificate :) - see my old post on this.
Then, generate a branch of new certs with signing requests on the vCloud Director.
The trick is: there are at least 2 "keytool" commands on a vCD server, one from the OS default (God knows what version) and one from the vCD installation, that should be used by us. Please note, that the "keystore" command version changes with vCD versions (as JRE version changes with it too), and of course the command syntaxes change too...
So, generate 2 certificates and their signing requests on the vCD node:

• /etc/init.d/vmware-vcd stop
• cd /opt/vmware/vcloud-director
• jre/bin/keytool -keystore certificates.ks -storetype JCEKS -storepass mypasswd -genkey -keyalg RSA -alias http -validity 3650
• jre/bin/keytool -certreq -keystore certificates.ks -storetype JCEKS -storepass mypasswd -alias http -file http.csr
• jre/bin/keytool -keystore certificates.ks -storetype JCEKS -storepass mypasswd -genkey -keyalg RSA -alias consoleproxy -validity 3650
• jre/bin/keytool -certreq -keystore certificates.ks -storetype JCEKS -storepass mypasswd -alias consoleproxy -file consoleproxy.csr

The "alias" names are mandatory to the 2 vCD IPs. When keystore asks "What is your first and last name?" the answer should be the IP addresses resolvable FQDN - 2 different FQDNs for the 2 IPs.

Now, copy the 2 .csr files over your signing machine, where the root certificate AND it's key file resides.

Sign the 2 signing requests, thus generating signed certificates.

• openssl x509 -req -in http.csr -CA myroot.crt -CAkey rui.key -CAcreateserial -out http.crt -days 3650
• openssl x509 -req -in consoleproxy.csr -CA myroot.crt -CAkey rui.key -CAcreateserial -out consoleproxy.crt -days 3650

Now, copy over the 2 newly generated certificates and the root certificate (not it's key!) to the vCD node.

Then, we should import the root certificate and the 2 signed certificated into the keystore:

• cd /opt/vmware/vcloud-director
• jre/bin/keytool -importcert -storetype JCEKS -storepass mypasswd -keystore certificates.ks -file myroot.crt -alias root
• jre/bin/keytool -importcert -storetype JCEKS -storepass mypasswd -keystore certificates.ks -file http.crt -alias http
• jre/bin/keytool -importcert -storetype JCEKS -storepass mypasswd -keystore certificates.ks -file consoleproxy.crt -alias consoleproxy
• You can check if the keystore is all right (should be) with: jre/bin/keytool -storetype JCEKS -storepass mypasswd -keystore certificates.ks -list
• Then, reconfigure vCD: /opt/vmware/vcloud-director/bin/configure - the store now should be at /opt/vmware/vcloud-director/certificates.ks
• And finally, start the service: /etc/init.d/vmware-vcd start

This should be all!

Axis P3343 IP Cam

The same thing as in 225FD works. This time I modified /etc/init.d/zzz script...

Embedded linux on the Axis 225FD IP Camera

Now this post has nothing to do with VMware.
I managed to get hold on an Axis 225FD IP camera (EOL already) powered by the Axis made ETRAX 100LX CPU, which is a simplified 32 RISC CPU (see http://kernel.org/doc/Documentation/cris/README).
First I flashed the latest firmware (and probably the last released one) on the device, 4.49.
The output was promising:

Preparing system for upgrade ...
Starting run level 4 (stop most daemons) ...
Waiting for run level 4 to start ...
Run level 4 started.
Waiting for run level 4 to finish ...
... waiting ...
... waiting ...
... waiting ...
... waiting ...
... waiting ...
Run level 4 finished.
Stopping some remaining processes.
sending TERM signal ...
Most processes stopped.
The file system will be upgraded after reboot.
Unmounting file system /var ...
Unmounting file system /mnt/flash ...
File systems successfully shut down.
found magic
Receiving new firmware ...
Receiving new firmware ...
Receiving new firmware ...
Erasing old file system ...
/dev/part/kernel
1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11% 12%
13% 14% 15% 16% 17% 18% 19% 20% 21% 22% 23% 24%
25% 26% 27% 28% 29% 30% 31% 32% 33% 34% 35% 36%
37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48%
49% 50% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60%
61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 71% 72%
73% 74% 75% 76% 77% 78% 79% 80% 81% 82% 83% 84%
85% 86% 87% 88% 89% 90% 91% 92% 93% 94% 95% 96%
97% 98% 99% 100%
Loading new file system ...
/dev/part/kernel
1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 11% 12%
13% 14% 15% 16% 17% 18% 19% 20% 21% 22% 23% 24%
25% 26% 27% 28% 29% 30% 31% 32% 33% 34% 35% 36%
37% 38% 39% 40% 41% 42% 43% 44% 45% 46% 47% 48%
49% 50% 51% 52% 53% 54% 55% 56% 57% 58% 59% 60%
61% 62% 63% 64% 65% 66% 67% 68% 69% 70% 71% 72%
73% 74% 75% 76% 77% 78% 79% 80% 81% 82% 83% 84%
85% 86% 87% 88% 89% 90% 91% 92% 93% 94% 95% 96%
97% 98% 99% 100%
The system upgrade completed successfully.
The unit will now reboot.
To continue, please connect to the unit again.
There may be a short delay before the new connection is accepted.
This connection will now close.

 So it does run Linux :)
Next, I enabled the ftp feature on the system. After logging on with the meaningful "root" account, I saw this:

Connected to 192.168.0.90 (192.168.0.90).
220 AXIS 225FD Network Fixed Dome Camera 4.49 (Mar 15 2010) ready.
Name (192.168.0.90:root): root
503 Bad sequence of commands.
SSL not available
331 User name okay, need password.
Password:
230 User logged in, proceed.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 Command okay.
150 Opening data connection.
-rw-r--r-- 1 root root 30720 Mar 15 2010 .var.tar
drwxr-xr-x 1 root root 2444 Mar 15 2010 bin
drwxr-xr-x 1 root root 2020 Mar 15 2010 dev
lrwxrwxrwx 1 root root 13 Mar 15 2010 etc -> mnt/flash/etc/
drwxr-xr-x 1 root root 1228 Mar 15 2010 lib
-rwxr-xr-x 1 root root 1555 Mar 15 2010 linuxrc
drwxr-xr-x 1 root root 104 Mar 15 2010 mnt
dr-xr-xr-x 78 root root 0 Oct 18 11:08 proc
drwx------ 1 root root 0 Mar 15 2010 root
drwxr-xr-x 1 root root 588 Mar 15 2010 sbin
drwxr-xr-x 1 root root 16 Mar 15 2010 share
drwxr-xr-x 11 root root 0 Oct 18 11:08 sys
lrwxrwxrwx 1 root root 7 Mar 15 2010 tmp -> var/tmp/
drwxr-xr-x 1 root root 120 Mar 15 2010 usr
drwxr-xr-x 10 root root 200 Oct 18 11:08 var
226 Transfer complete.
ftp>

LOL, I got into the root directory of the device filesystem over the factory ftp server just using the root account. And yes, everything is writable.
Next stop, start looking at the filesystem with some more visual tool (I prefer mc :). It looks like an industry standard embedded linux, with busybox and such. And voilà! There IS a /usr/sbin/telnetd symlink, which points to the busybox binary. Now I just had to start it.
Looking at /etc/init.d/ there is a start script called http - the boa web server, which is mandatory starting with the device. Adding one line (/usr/sbin/telnetd)" into the start section does the trick.
After a reset of the device i just do a telnet and do the victory dance.

root@sysresccd /root % telnet 192.168.0.90
Trying 192.168.0.90...
Connected to 192.168.0.90.
Escape character is '^]'.


4.49
Linux 2.6.27 on a cris (12:37:54)
axis-00408c957432 login: root
Password:
[root@axis-00408c957432 /]659#

Remember the hacker movies of the 90's? I'm in :)
Some more goodies:

[root@axis-00408c957432 /]659# uname -a
Linux axis-00408c957432 2.6.27 #1 Mon Mar 15 11:24:43 CET 2010 cris unknown
[root@axis-00408c957432 /]659# dmesg
Linux version 2.6.27 (bogw@eater-1) (gcc version 3.2.1 Axis release R64/1.64) #1 Mon Mar 15 11:24:43 CET 2010

And of course:

[root@axis-00408c957432 /]659# ps
PID Uid VmSize Stat Command
1 root 232 S init
2 root SW< [kthreadd]
3 root SW< [ksoftirqd/0]
4 root SW< [events/0]
5 root SW< [khelper]
20 root SW< [kblockd/0]
37 root SW [pdflush]
38 root SW [pdflush]
39 root SW< [kswapd0]
40 root SW< [aio/0]
78 root SW< [mtdblockd]
103 root SWN [jffs2_gcd_mtd2]
166 root 440 S /bin/sh
171 root 248 S /sbin/respawnd
175 root 264 S /bin/log_combiner -o40000
184 root 304 S /usr/sbin/syslogd -m 0 -o 40000
188 root 264 S /usr/sbin/klogd -x
194 root 248 S /sbin/ipchanged -e /etc/ipchanged.script
279 root 272 S /sbin/zeroconf-ip -i eth0
290 root 256 S /usr/bin/bw --directory /var/cache/bw --text-file bw
314 root 312 S /bin/time_handler
321 root 336 S /bin/vftpd -r -q 0 -Q 0
326 root 240 S /bin/client_counter -d
332 root 608 S /bin/parhand /dev/null 50011 -d /usr/etc/param -d /et
347 root 304 S /bin/axisns add -w -d
360 root 520 S /bin/infod
363 root 520 S /bin/infod
364 root 520 S /bin/infod
372 root 520 S /bin/infod
374 root 520 S /bin/infod
376 root 336 S /bin/vcd
390 root 656 S N /bin/image_viewer -q 0 -N 10
392 root 656 S N /bin/image_viewer -q 0 -N 10
393 root 656 S N /bin/image_viewer -q 0 -N 10
395 root 656 S N /bin/image_viewer -q 0 -N 10
397 root 656 S N /bin/image_viewer -q 0 -N 10
398 root 656 S N /bin/image_viewer -q 0 -N 10
400 root 656 S N /bin/image_viewer -q 0 -N 10
401 root 656 S N /bin/image_viewer -q 0 -N 10
402 root 656 S N /bin/image_viewer -q 0 -N 10
403 root 656 S N /bin/image_viewer -q 0 -N 10
404 root 656 S N /bin/image_viewer -q 0 -N 10
405 root 656 S N /bin/image_viewer -q 0 -N 10
407 root 656 S N /bin/image_viewer -q 0 -N 10
409 root 656 S N /bin/image_viewer -q 0 -N 10
411 root 656 S N /bin/image_viewer -q 0 -N 10
414 root 656 S N /bin/image_viewer -q 0 -N 10
415 root 656 S N /bin/image_viewer -q 0 -N 10
418 root 656 S N /bin/image_viewer -q 0 -N 10
421 root 656 S N /bin/image_viewer -q 0 -N 10
423 root 656 S N /bin/image_viewer -q 0 -N 10
426 root 656 S N /bin/image_viewer -q 0 -N 10
429 root 656 S N /bin/image_viewer -q 0 -N 10
432 root 656 S N /bin/image_viewer -q 0 -N 10
440 root 392 S /bin/recorder --backend /lib/recorder/artpec2-jpg.so
441 root 184 S /bin/recorder_cache_manager
463 root 552 S < /bin/media_server -R --nice -1 -r 3
497 root 280 S /bin/utask -f /etc/task.list -f /etc/user.task.list -
513 root 232 S /bin/mld /var/log/crit_mld_pipe -w /var/log/warning_m
531 root 752 S /usr/bin/motion -c /etc/emotiond.conf
541 root 368 S /bin/iod
547 root 560 S /bin/ssid
553 root 256 S /bin/ird /dev/cam0
559 root 600 S /usr/bin/tampering -c /etc/tampering.conf
571 root 272 S /bin/lang_handler
577 root 416 S /usr/sbin/telnetd
579 root 760 S /bin/boa -c /etc/httpd/conf
585 root 264 S /bin/sersrvd -d
605 root 280 S /usr/sbin/debugar.cgi
659 root 448 S -sh
668 root 376 R ps

On terms of security (as this is a security product)... we shall not speak again about the possibility of logging in as root.

vCenter SQL and MSDB

Now, this is probably not new for most peeps. I just keep looking up this again and again, so here's a quickie.
vCenter MSSQL user requires permissions to the MSDB system database. It shall give you a misleading warning at install time if it doesn't get the rights:

See the VMware documentation for more info on this.
Also, Single Sign On service requires a user with Sysadmin privileges - see this documentation page.

Regards,

Nexus 1000v correct ports

I always forget - so this is a note:
Nexus 1000v ports should be connected as:
- Ethernet 1: Control
- Ethernet 2: Management
- Ethernet 3: Packet

see Cisco.

C-M-P

Cheers.

vCenter appliance 5.0u1 - certificate replacement - OpenSSL

This is just another piece of my OpenSSL headshot. I won't format it better, if you need this you can use it.
Been using this unsatisfactory kb, this forum post for reference.
This blog spot contains some of the information you can find here. Some differences though (he forgets to mention that the password for /usr/lib/vmware-vsphere-client/server/config/keystore is changeit for example)

vcVA stores it's certificates @ many different places:

• /opt/vmware/etc/lighttpd/server.pem - The vami management interface's (port 5480) https certificate
• /etc/vmware-vpx/ssl/ - VPX service's certificate (also TomCat), keys are stored here for SQL communication
• /usr/lib/vmware-vpx/inventoryservice/ssl/ - Inventory service's certificate
• /usr/lib/vmware-vsphere-client/server/config/keystore - Web Client's certificate
• /etc/ssl/certs/ - Root CA PEMs, if needed

You can generate the required (unencrypted) rui.key & rui.crt from the previous article. Rui.pfx is regenerated by the appliance, so not really needed to care for.

It is slightly easier, if you haven't yet initialized the DB - the DB connection is using the rui.crt from vpxd, if it is already initialized it has to be changed in sms.keystore & sms.truststore :( .
That must be something secret, as nobody ever published any howto on it. I should have, but I'm just too lazy...

So, for the fresh install:

1. # cp rui.* /usr/lib/vmware-vpx/inventoryservice/ssl/ - Inv. service's cert has to be replaced manually
2. # vpxd_servicecfg eula accept - Or accept it on GUI, if you haven't
3. Configure the database, for example the embedded can be initialised using:
   # vpxd_servicecfg db write embedded
4. Change the certs for vpxd and vami:
   # vpxd_servicecfg certificate change rui.crt rui.key - This also changes the management GUI cert (concatenates the .key and .crt files into server.pem)
5. Change the cert for Web Client:
   # cd  /usr/lib/vmware-vsphere-client/server/config/
   # mv keystore keystore.orig
   # /usr/lib/vmware-vpx/jre/bin/keytool -keystore keystore -importcert -file rui.crt -alias s2dmk -storetype JKS -storepass changeit - changeit is the default password for the keystore. Don't change it ;)
   # /usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh unregister https://localhost:9443/vsphere-client localhost root vmware - vmware is the assumed root password.
   # /usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh unregister https://FQDN:9443/vsphere-client localhost root vmware - Press A to Accept the certificate. Set FQDN, localhost might not work.
6. (Re)Start the whole thing
   # /etc/init.d/vami-lighttp restart
   # /etc/init.d/vmware-vpxd start
   # /etc/init.d/vsphere-client restart
   Or just reboot.

You can check for any errors in /var/log/vmware/vpx/.
That's all, hope you don't mind...