Creating eDirectory SSL certificates with alternate names to use across round robin DNS load balanced web servers


We have three internal Apache web servers that we use for Groupwise webaccess 7.0.3.  Each server will be accessed acrossed our intranet via round robin DNS at https://webaccess/gw/webacc for email.  When users currently access this URL they are getting Internet Explorer Security Alerts, stating:  

The name on the security cerrtificate is invalid or does not match the name of the site.  Do you want to proceed?
 
In order to fix this issue, I need to install SSL certificates on each individual server and configure Apache to use the new certificates.  I also needed to configure my web browser to trust the issuing Certificate Authority.
 
I chose to use our existing Novell Organizational CA to issue the certificates rather than purchase one from Verisign or other Trusted Root Certification Authority since these sites would only be accessed across the corporate intranet.
 
We had one additional requirement – each server still needed to be accessed via https at https://servername for Novell Remote Manager and iManager.  This meant the three servers had to have valid SSL certificates for multiple host names, i.e. both their actual name and the webaccess name.

The Environment

  • Three Netware 6.5.5 server running Apache 2.0.54 for Netware. Servers are named web1, web2, and web3
  • ConsoleOne 1.3.6f
  • Novell Certificate Server Snapin version 2.21 Build 28
  • Internet Explorer 6 web browser
 Creating the server SSL certificates
 
1.  Launch ConsoleOne
 
2.  Browse to the OU that holds the servers you wish to create certificates for.
 
3.  Right click on the server OU
 
4.  Select New – Object – NDSPKI:Key Material – OK
 
5.  Select the server name you want to create the certificate for, and give the certificate a meaningful name.  I named mine intwebaccessweb1
 
6.  Under Creation Method, select Custom – Next
 
7.  Select Organizational Certificate Authority will sign this certificate – Next
 
8.  Accept the defaults of 2048 bit key size, SSL or TLS type, and allow the private key to be exported – Next
 
9.  This is an important part – The subject name must match how you will be accessing your server over https for iManager and NRM.  Click the Edit button, then click the double arrow button to the right of the subject name.  This will move the .CN= portion of the name to the left side of the box.
Replace everything from .CN= to .OU= (or .O=) with the name you will be accessing your server with.  

Since I will be accessing my server at https://web1, I used .CN=web1.O=myOrg.  

If you will be accessing your server for iManager, NRM, or other non-shared services at https://www.yourdomain.com you would enter .CN=www.yourdomain.com.O=yourOrg

10.  Press OK  to accept the subject name.
 
11.  Change the validity period to what ever duration you would like your certificate to be valid for.  I selected maximum, which will make it good until the certificate for my Organizational CA expires.
 
12.  Press the Add Name button – here is where we specify our secondary name we want the SSL certificate to be valid for.
 
13.  Highlight the existing Directory name and press Delete.
 
14.  Click Create – DNS Name
 
15.  Specify the host name you will be sharing amongst your web servers.  This is sometimes referred to as a DNS Subject Alternate Name
 
I specified webaccessOKOKNext.  Again, if you will be accessing your shared web server at https://www.yourdomain.com, specify http://www.yourdomain.com as the DNS name.
 
16.  Select to associate this server certificate with Your organization’s certificate – NextFinish
 
I then repeated these steps for my other two web servers, replacing in steps 5 and 9 ‘web1′ with ‘web2′ and ‘web3′, which are the real host names of my other web servers.  Step 15 remains the same, since this is the common name I want all three web servers to respond to.
 
Configuring Apache to use the new SSL certificates
 
1.  On the first web server edit the sys:\Apache2\conf\httpd.conf file.
 
2.  Replace the line reading
 
SecureListen 443 “SSL CertificateDNS”
 
with
 
SecureListen 443 “intwebaccessweb1″
 
where intwebaccessweb1 is the name of the web server you created in the section above.  Note that the certificate object will be displayed in ConsoleOne as ‘intwebaccessweb1 – web1′.  Do not include the hyphen and server name, i.e. ‘ – web1‘ in the SecureListen statement.
 
3.  Save the httpd.conf file
 
4.  On the web server console, run ap2webdn to unload Apache
 
5.  On the web server console run tc4stop to stop Tomcat
 
6.  On the web server console, run tckeygen to update the keystore data.  Switch to the logger screen to verify the process completes before proceeding to the next step.
 
7.  On the web server console, run tomcat4 to load Tomcat.  Switch to the logger screen to verify the process completes before proceeding to the next step.
 
8.  On the web server console, run ap2webup to load Apache.
 
9.  Browse to the shared name of your web server, https://webaccess/gw/webacc in my case.  Note that you will still receive the Security Alert pop-up until you install the Organizational CA certificate into your Trusted Root Certification Authorities store, which I’ll document tomorrow.
 
10.  On the Security Alert pop-up, you should see the message stating The security certificate has a valid name matching the name of the page you are trying to view.
 
This means your SSL certificate is valid for the host name shared by the web servers.
 
11.  Browse to https://web1, which is the host name of one of your web servers defined in step 9 of Creating the server SSL certificates.  
 
Again, you’ll still receive the Security Alert until you install the Organizational CA certificate into your Trusted Root Certification Authorities store, but you should see The security certificate has a valid name matching the name of the page you are trying to view.  This means your SSL certificate is valid for the host name for this specific web server.
 
Here are the instructions for installing the Organizational CA certificate into your browser’s Trusted Root Certification Authorities store, which is the final thing we’ll need to do to rid ourselves of the Internet Explorer’s Security Alerts.

Howto: Redirect Groupwise 6.5 url /servlet/webacc to Groupwise 7 URL /gw/webacc


Groupwise 6.5 WebAccess is accessed via http://yourserverDNSorIP/servlet/webacc, while Groupwise 7.0 WebAccess is accessed at http://yourserverDNSorIP/gw/webacc.  Here’s how to configure Apache to redirect the old WebAccess url to the updated one:

1) On the Netware server, edit sys:\apache2\conf\httpd.conf 

2) At the bottom of the file paste the following line:

redirect permanent /servlet/webacc http://yourserverDNSorIP/gw/webacc

replacing yourserverDNSorIP with your server’s DNS name or IP address

3) On the Netware console unload Apache by running

ap2webdn

4) On the Netware console load Apache by running

ap2webup

If you access  http://yourserverDNSorIP/servlet/webacc with your web browser, you should now be redirected to http://yourserverDNSorIP/gw/webacc

Basic Apache Hardening in SLES 10


I setup a SuSE Enterprise Linux (SLES) 10 SP2 web server last week, and wanted to do some basic hardening of the default Apache configuration.  Here’s what I did.

  1. edit /etc/apache2/httpd.conf
  2. Add RewriteEngine On
  3. Add RewriteLogLevel 2
  4. Add RewriteLog /var/log/apache2/rewrite.log
  5. Add ServerSignature Off
    The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents
  6. Add ServerTokens Prod
    This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules
  7. Add ErrorDocument 500 “Internal server error” to return a generic error message when http 500 error occurs
  8. Add ErrorDocument 404 “An unknown error occurred, please try again later”  (http 404 = not found)
  9. Add ErrorDocument 403 “An unknown error occurred, please try again later”    (http 403 = forbidden)
  10. Save – exit httpd.conf
  11. touch /var/log/apache2/rewrite.log to create the rewrite.log file
  12. touch /srv/www/htdocs/.htaccess to create the .htaccess file
  13. Edit the /srv/www/htdocs/.htaccess file
  14. Add Options +FollowSymLinks –MultiViews
    Note: FollowSymLinks must be set to + for rewrite to work!
  15. Add rewrite rules appropriate for your environment.  I’m using some rules that can be found in the Pauldotcom Security Weekly episode #94 show notes, which were based on a post by nullbyte.
  16. Save – exit .htaccess
  17. YaST – Network Services – HTTP Server
  18. Server Modules tab – rewrite – toggle status to enabled – finish
  19. From a terminal run: SuSEconfig
  20. From a terminal run: /etc/init.d/apache2 restart
  21. With a web browser, try to access a page on the server that does not exist, ie  http://server/nothere.html
  22. View the  /var/log/apache2/rewrite.log 
    You should see the attempt logged

Accessing Netware iManager on Apache results in 503 error


Last Wednesday I updated one of my Netware 6.5.7 / Zenworks 7.0.1 servers, and rebooted it to make sure everything came us as expected.  Apache loaded fine, and when I went to http://serverIP, everything worked great.  But when I attempted to access iManager at  http://serverIP/nps/iManager.html, I received a 503 error from Apache.  The same results were observed when accessing the sites through https rather than http.

To fix this problem, I modified instructions posted by Baudizm.  You can find my comments enclosed in [ ]

On the server console I ran:

tc4stop   [stops Tomcat]

ap2webdn  [stops Apache]

java -exit  [stops Java]

pkidiag  [loads PKI diagnostic utility]

authenticate as admin equivalent user

[select pkidiag options] 4 – 5 – 6 – 0

tckeygen  [for LDAP]

tomcat4  [loads tomcat]

Ap2webup  [loads Apache web server]

After performing these steps, iManager loaded with no problem.

Additional Resources

TID 3377845 error 503 returned by applications that use Tomcat, is a good resource for fixing tomcat/tckeygen related problems.

TID 3640106, How to Use PKIDIAG to avoid issues while Installing Netware 6.5 goes into detail on how pkidiag works and how to troubleshoot vertificate problems.

TID 3234091 Tomcat4 does not load, talks about using Tckeygen to fix .keystore problems.

Groupwise Webaccess Loads, but Users Cannot See Webaccess Login Screen


Saturday I received a frantic call from the network administrator of a client.  Their Groupwise 7.0.2 system that runs on a Netware 6.5.7 server had suddenly become inaccessible from both the Internet and local network for Webaccess clients.  Users who used the full Groupwise client reported no issues.

The local admin had performed some troubleshooting prior to contacting me.  She had rebooted the server several times, confirmed Webaccess was loading, verified Webaccess was inaccessible from both the standard URL and IP based URL, i.e. https://mail.domain.com/gw/webacc and https://10.0.0.6/gw/webacc.  She also verified there was nothing odd logged in the Webaccess log files. 

On the Netware server console I typed m ap* to see if the apache2.nlm was loaded.  The .nlm was not listed, so I typed ap2webup.ncf to try to load the Apache web server.  I did not receive an error about Apache not loading, and the logger screen did not show any errors, but when I typed m ap* again, Apache2.nlm was still not listed.

I was fairly certain this was an Apache, not Groupwise Webaccess problem, so I checked out the most recent error_log file in my Sys:\Apache2\logs folder, where I found the following message:

[Sat Apr 26 13:37:23 2008] [crit] (10022)Unknown error: make_secure_socket: for port 443, WSAIoctl: (SO_SSL_SET_SERVER) Configuration Failed

I did some searching and came across TID 3209228 Apache for Netware will NOT load any longer.  This article pointed to a certificate problem being the reason why Apache would not load.

I followed the TID’s advice and performed the following from the Netware server console:

  1. Load pkidiag.nlm
  2. Login as admin (or someone with appropriate rights to create certificates)
  3. Select options 4, 5, 6, 0
  4. run tckeygen.ncf
  5. Rebooted the server

Once the server restarted, Apache loaded succesfully, and the Groupwise Webaccess login screen was once again available for web clients.

Follow

Get every new post delivered to your Inbox.

Join 32 other followers