Solving APC / Schneider Electric UPS PR_CONNECT_RESET_ERROR / ERR_CONNECTION_RESET / Connection Reset

Problem:

Web-browser reports PR_CONNECT_RESET_ERROR or ERR_CONNECTION_RESET when trying to manage APC via https.

Cause:

SSL certificate invalid.

Solution:

https://www.apc.com/us/en/faqs/FAQ000233142/

ssh -c aes256-cbc <IPAddress>
cd ssl
dir
delete <filename>.p15
reboot

HTTPS should work after restart.

Alternative Solution:

ssh -c aes256-cbc <IPAddress>
web -h enable 
reboot

Connect via HTTP and Delete the certificate via Web UI
Navigate to Configuration --> Network --> Web --> SSL Certificate --> Select “Remove” --> Apply.
Navigate to Control --> Network --> Reset/Reboot --> Select “Reboot Management Interface” --> Apply.

HTTPS should work after restart.

Revert HTTP to disabled if desired.

Recommended:

Update firmware, but newest firmware seemingly still using CBC ciphers. 😩

---

good luck!

AH00072

Problem:
Previously working, but now
Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443

Probable Cause:
Any two or more .conf files have Listen 443 or <VirtualHost _default_:443> in them.

Tentative Solution:
Edit your /etc/httpd/httpd.conf or other /etc/httpd/conf.d/*.conf files making sure you don’t have two files requesting port 443. It seems recent Apache versions are more strict and will fail to run, whereas older versions did not complain. Technically, I just the renamed /etc/httpd/conf.d/ssl.conf to /etc/httpd/conf.d/ssl.conf.OFF so that my actual /etc/httpd/conf.d/live_ssl.conf file was used.
  

vCenter Server Appliance (vCSA) 5.5 SSL certificate replacement and root password reset the hard and/or easy way. (or The vCSA is Dead, Long Live the vCSA)

It all started because my SSL certificate was expired and with recent updates to Chrome and Firefox we could not login. I found this perfect article (http://www.virtuallyghetto.com/2013/04/automating-ssl-certificate-regeneration.html) to regenerate the certificate via commandline, but i was locked out of the root account. I thought, as many do, that i had forgotten the root password, but it turns out that with v5.5, root passwords expire in 90 days and if you don't set an SMTP server and email address, you will never be notified. Furthermore after some time the account will be locked.

On the vCSA console you have an option to Login. I don't really know why, but somehow after failing some logins or semi-resetting the account, i found that if i mistyped the password 3 times, i would actually get the root prompt. Now if you cannot get the root prompt, luckily you can use this excellent method (http://www.virtuallyghetto.com/2013/09/how-to-recover-vcsa-55-from-expired.html) to get to the files also. If you do use the link's method, please note that you will need to mount/remount with read-write access which is not mentioned. hint: mount -o remount,rw /mnt

So in the following commands, you will see [/mnt]. What i mean by this is that if you use the link's method, then you need /mnt/path ; however, if were able to get the vCSA's root prompt, then simply use the /path (excluding /mnt)

Of course you should bakup any files you plan to change!

We will use vi because it's the editor built into the vCSA. Remember in vi you can i or a to insert or append to get into typing mode. Afterward, <esc>wq! to force save & quit or <esc>q! to abort and quit.

Firstly, i found that the password policy required a new, previously unused, password that had to meet complexity requirements. This sucked tremendously considering i really really wanted to re-use the password. If you wish to do the same try this, if not skip it.

change root password policy with vi [/mnt]/etc/pam.d/common-password

change

password        requisite       pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=8 difok=4 retry=3
password        required        pam_pwhistory.so enforce_for_root remember=4 retry=3

to

password        requisite       pam_cracklib.so dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minlen=8 difok=0 retry=0
password        required        pam_pwhistory.so enforce_for_root remember=0 retry=3

The above should set that the password does not need to have to be significantly different from prior passwords and not to spam the prompt requesting retries.

An alternative way might be to purge the password history file with rm [/mnt]/etc/security/opasswd which of course i did.

If you can get to the vCSA's root prompt, then you can change the root password with passwd

However, if you cannot, then potentially you can reuse your old password by reinstantiating the password hash from a backup shadow.* file. Revisit the above mentioned article (http://www.virtuallyghetto.com/2013/09/how-to-recover-vcsa-55-from-expired.html) as it explains the shadowfile.

Thusly, I was successful with restoring the default password of vmware by finding that [/mnt]/etc/shadow.UPDATE contained its hash. I copied the hash (installation specific i'm sure) into the existing [/mnt]/etc/shadow's root line and made sure the 5th field was nothing (::). it looked like such:

root:$2y$10$Gye6636Oxy/2yK01.7MW0ud8pSE90cEYr92kLSwDvJmULjmTPnu0O:16581:0:90:7:::

Once I had accomplished all this, i rebooted and was able to login with vmware. I reset my password with passwd at the root prompt. It complained it was too simple a password, but accepted it none-the-less.

Note: Through all this, I found that the actual client login Administrator@vSphere.local had never changed changed, so don't expect it to be the new one you just changed.

Futhermore, I followed this very fitting article (http://www.virtuallyghetto.com/2013/09/administrator-password-expiration-in.html) to completely disable root password expiration with chage -M -1 -E -1 root.

If you use VMWare Update manager (VUM), you may need to remmediate it's connection with http://kb.vmware.com/kb/2048210.

In addition to the resources linked above, the following were referenced during my adventure-less adventure.

• (http://www.cyberciti.biz/faq/rhel-fedora-centos-linux-password-quality-control/)
• (http://www.vladan.fr/how-to-change-the-default-password-policies-in-vsphere-5-5/)
• (http://www.vladan.fr/how-to-unlock-the-vmware-vcsa-root-password/)
• (http://www.itworld.com/article/2726217/endpoint-protection/how-to-enforce-password-complexity-on-linux.html)

My other recent posts also relate to this issue due to Mozilla, Google and Microsoft weak SSL deprecation policies.

• http://steronius.blogspot.com/2015/09/vcenter-chrome-45-errsslweakserverephem.html
• http://steronius.blogspot.com/2015/08/https-ssl-cipher-remediation-for.html

---
As Always, Good Luck!

Please comment or tip me or use any/all of my affiliate links; Thank YOU!

You can thank me with bitcoin.    

VMWare vCenter vSphere Web Client Chrome 45 ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY

VMWare vCenter vSphere Web Client + Chrome 45
Server has a weak ephemeral Diffie-Hellman public key
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY
a.k.a Forward Secrecy

I patched this together rather quickly, but i think it's all here!  Today we had issue with Chrome 45 failing to connect to VMWare 5.1 vCenter vSphere Web Server (vSphere Web Client).  This is how I fixed it. (Also seems to work in Firefox.)

create new self-signed certificate (in linux):

openssl genrsa 2048 > rui.key
openssl req -new -key rui.key > rui.csr
#openssl x509 -in rui.cer -out rui.crt
openssl x509 -req -days 1825 -in rui.csr -signkey rui.key -out rui.crt
openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

you must use testpassword if you retain the default tomcat keystorePass setting in the xml mentioned below.

backup and replace files in C:\Program Files\VMware\Infrastructure\vSphereWebClient\DMServer\config\ssl\ with the files just created.  *** my other vCenter did not have this folder. It was C:\Program Files\VMware\Infrastructure\vSphereWebClient\logbrowser\conf\ instead. (upgrade vs. fresh install?)

edit C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\config\tomcat-server.xml

was

        <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="500" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" ciphers="SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_DSS_WITH_AES_128_CBC_SHA" keystoreFile="C:\ProgramData\vmware\vSphere Web Client\ssl\rui.pfx" keystorePass="testpassword" keystoreType="PKCS12"></Connector>

changed to (removed RC4 and DHE-only ciphers)

        <Connector port="9443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="500" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_RSA_WITH_AES_256_CBC_SHA, TLS_DH_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DH_RSA_WITH_AES_128_CBC_SHA, TLS_DH_DSS_WITH_AES_128_CBC_SHA" keystoreFile="C:\ProgramData\vmware\vSphere Web Client\ssl\rui.pfx" keystorePass="testpassword" keystoreType="PKCS12"></Connector>

restart both vspherewebclientsvc and vctomcat services. Be patient, it will take a few minutes for the services to be ready to serve the web-pages correctly.

resources used:
http://www.vkernel.ro/blog/replacing-vmware-vcenter-server-default-self-signed-certificate
https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl
https://www.chromium.org/administrators/err_ssl_weak_server_ephemeral_dh_key

My other recent post (https SSL cipher remediation for webservers 2015) is also related due to Mozilla, Google and Microsoft weak SSL deprecation policies.

---
As Always, Good Luck! 
Please comment or tip me or use any/all of my affiliate links; Thank YOU!
If I saved your ass, you can thank me with bitcoin.    

https SSL cipher remediation for webservers 2015

I don’t know jack! I am NOT a security professional by trade, but please at least be aware that simply installing an SSL certificate on your server does NOT make it secure.

Thanks to Qualys SSL Labs (https://www.ssllabs.com/ssltest/), testing your server for SSL security is dead simple. I recommend every public site you manage to be tested immediately!

Once you know your status, here are some invaluable information resources you will need for remediation:

Configuring Apache, Nginx, and OpenSSL for Forward Secrecy : https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Setup your [Windows] IIS for SSL Perfect Forward Secrecy and TLS 1.2 : https://www.hass.de/content/setup-your-iis-ssl-perfect-forward-secrecy-and-tls-12

Additionally I had one server that used stunnel (https://www.stunnel.org) on Windows. I found the following was good settings for C:\Program Files (x86)\stunnel\stunnel.conf:

sslVersion = all
options = NO_SSLv2
options = NO_SSLv3

ciphers = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4

Again, I am NOT a security expert, so please do not blindly reconfigure your settings without fully understanding what you are doing. I do not think my advice is wrong, but there absolutely might be better settings available.

Here is a good Mozilla resource for Server Side TLS (https://wiki.mozilla.org/Security/Server_Side_TLS) including a link to Mozilla SSL Configuration Generator (https://mozilla.github.io/server-side-tls/ssl-config-generator/)

As Always, Good Luck!

Please comment or tip me or use any/all of my affiliate links; Thank YOU!

You can thank me with bitcoin.    

---

Redirect http to https on Apache server (httpd)

After googling http to https redirect, I found several answers that simply did not work (for me).  Finally I came across one that did:

In the directory of your web-content, create the file .htaccess and fill it with these directives:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI}

That's it.

This worked on CentOS 6.3 and Apache 2.2.15

p.s. Don't forget your firewall settings.
Please consider crypto tipping: