Also I remember having to have three parts with openssl on Linux. SSLCertificateFile /etc/apache2/ssl/basinc.biz.crt SSLCertificateKeyFile /etc/apache2/ssl/basinc.biz.key
Then I remember having to merge two files together to create the chain file (just using a basic unix cat command I believe) SSLCertificateChainFile /etc/apache2/ssl/startssl.chain.class1.server.crt I remember these two links being helpful: Of course its all openssl based. Not sure how the gsk stuff works with IBM. http://jasoncodes.com/posts/startssl-free-ssl http://lowtek.ca/roo/2012/ubuntu-apache2-trusted-ssl-certificate-from-startssl/ On Mon, Feb 18, 2013 at 8:14 AM, John Thompson <jthompson...@gmail.com>wrote: > So I'm guessing you aren't using the open source version of apache, but, > the IBM AIX flavor of it. > Which I'm guessing is IHS. > > I've never worked with that before. > Does the customer have IBM support? Maybe they have some guru that can > send you an example? > > I have some notes on this on Linux. > > Here is an example of a virtual host section that did work with ssl on > Apache on Linux (open source). > It did not use gsk and ihs, but, openssl and open source apache. > > I included the comments because I thought it might help. > BUT, all you need are the un-commented lines. > > </VirtualHost> > <IfModule mod_ssl.c> > > #May need this if not included elsewhere in apache config files. > #NameVirtualHost *:443 > #Listen 443 > > <VirtualHost *:443> > ServerAdmin some...@foo.com > ServerName foo.com > > DocumentRoot /var/www/somesite > > <Directory /var/www/somesite> > #Disable Options we don't need > Options -Indexes +Includes -ExecCGI +FollowSymLinks > -MultiViews > AllowOverride None > Order allow,deny > allow from all > </Directory> > > ErrorLog /var/log/apache2/error.log > > # Possible values include: debug, info, notice, warn, error, crit, > # alert, emerg. > LogLevel warn > > CustomLog /var/log/apache2/ssl_access.log combined > > Alias /doc/ "/usr/share/doc/" > <Directory "/usr/share/doc/"> > Options Indexes MultiViews FollowSymLinks > AllowOverride None > Order deny,allow > Deny from all > Allow from 127.0.0.0/255.0.0.0 ::1/128 > </Directory> > > # SSL Engine Switch: > # Enable/Disable SSL for this virtual host. > SSLEngine on > > # A self-signed (snakeoil) certificate can be created by > installing > # the ssl-cert package. See > # /usr/share/doc/apache2.2-common/README.Debian.gz for more info. > # If both key and certificate are stored in the same file, only > the > # SSLCertificateFile directive is needed. > SSLCertificateFile /etc/apache2/ssl/basinc.biz.crt > SSLCertificateKeyFile /etc/apache2/ssl/basinc.biz.key > > # Server Certificate Chain: > # Point SSLCertificateChainFile at a file containing the > # concatenation of PEM encoded CA certificates which form the > # certificate chain for the server certificate. Alternatively > # the referenced file can be the same as SSLCertificateFile > # when the CA certificates are directly appended to the server > # certificate for convinience. > SSLCertificateChainFile > /etc/apache2/ssl/startssl.chain.class1.server.crt > > # Certificate Authority (CA): > # Set the CA certificate verification path where to find CA > # certificates for client authentication or alternatively one > # huge file containing all of them (file must be PEM encoded) > # Note: Inside SSLCACertificatePath you need hash symlinks > # to point to the certificate files. Use the provided > # Makefile to update the hash symlinks after changes. > #SSLCACertificatePath /etc/ssl/certs/ > #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt > > # Certificate Revocation Lists (CRL): > # Set the CA revocation path where to find CA CRLs for client > # authentication or alternatively one huge file containing all > # of them (file must be PEM encoded) > # Note: Inside SSLCARevocationPath you need hash symlinks > # to point to the certificate files. Use the provided > # Makefile to update the hash symlinks after changes. > #SSLCARevocationPath /etc/apache2/ssl.crl/ > #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl > > # Client Authentication (Type): > # Client certificate verification type and depth. Types are > # none, optional, require and optional_no_ca. Depth is a > # number which specifies how deeply to verify the certificate > # issuer chain before deciding the certificate is not valid. > #SSLVerifyClient require > #SSLVerifyDepth 10 > > # Access Control: > # With SSLRequire you can do per-directory access control based > # on arbitrary complex boolean expressions containing server > # variable checks and other lookup directives. The syntax is a > # mixture between C and Perl. See the mod_ssl documentation > # for more details. > #<Location /> > #SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ > # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ > # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ > # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ > # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ > # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ > #</Location> > > # SSL Engine Options: > # Set various options for the SSL engine. > # o FakeBasicAuth: > # Translate the client X.509 into a Basic Authorisation. This > means that > # the standard Auth/DBMAuth methods can be used for access > control. The > # user name is the `one line' version of the client's X.509 > certificate. > # Note that no password is obtained from the user. Every entry > in the user > # file needs this password: `xxj31ZMTZzkVA'. > # o ExportCertData: > # This exports two additional environment variables: > SSL_CLIENT_CERT and > # SSL_SERVER_CERT. These contain the PEM-encoded certificates > of the > # server (always existing) and the client (only existing when > client > # authentication is used). This can be used to import the > certificates > # into CGI scripts. > # o StdEnvVars: > # This exports the standard SSL/TLS related `SSL_*' > environment variables. > # Per default this exportation is switched off for performance > reasons, > # because the extraction step is an expensive operation and is > usually > # useless for serving static content. So one usually enables > the > # exportation for CGI and SSI requests only. > # o StrictRequire: > # This denies access when "SSLRequireSSL" or "SSLRequire" > applied even > # under a "Satisfy any" situation, i.e. when it applies access > is denied > # and no other module can change it. > # o OptRenegotiate: > # This enables optimized SSL connection renegotiation handling > when SSL > # directives are used in per-directory context. > #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire > <FilesMatch "\.(cgi|shtml|phtml|php)$"> > SSLOptions +StdEnvVars > </FilesMatch> > <Directory /usr/lib/cgi-bin> > SSLOptions +StdEnvVars > </Directory> > > # SSL Protocol Adjustments: > # The safe and default but still SSL/TLS standard compliant > shutdown > # approach is that mod_ssl sends the close notify alert but > doesn't wait for > # the close notify alert from client. When you need a different > shutdown > # approach you can use one of the following variables: > # o ssl-unclean-shutdown: > # This forces an unclean shutdown when the connection is > closed, i.e. no > # SSL close notify alert is send or allowed to received. This > violates > # the SSL/TLS standard but is needed for some brain-dead > browsers. Use > # this when you receive I/O errors because of the standard > approach where > # mod_ssl sends the close notify alert. > # o ssl-accurate-shutdown: > # This forces an accurate shutdown when the connection is > closed, i.e. a > # SSL close notify alert is send and mod_ssl waits for the > close notify > # alert of the client. This is 100% SSL/TLS standard > compliant, but in > # practice often causes hanging connections with brain-dead > browsers. Use > # this only for browsers where you know that their SSL > implementation > # works correctly. > # Notice: Most problems of broken clients are also related to > the HTTP > # keep-alive facility, so you usually additionally want to > disable > # keep-alive for those clients, too. Use variable "nokeepalive" > for this. > # Similarly, one has to force some clients to use HTTP/1.0 to > workaround > # their broken HTTP/1.1 implementation. Use variables > "downgrade-1.0" and > # "force-response-1.0" for this. > BrowserMatch "MSIE [2-6]" \ > nokeepalive ssl-unclean-shutdown \ > downgrade-1.0 force-response-1.0 > # MSIE 7 and newer should be able to use keepalive > BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown > > </VirtualHost> > </IfModule> > > > On Sat, Feb 16, 2013 at 7:02 PM, Kevin King <ke...@precisonline.com>wrote: > >> Might anyone have any tips or tricks for getting SSL to work on the >> IBMIHS/Apache 2.0.47 web server on an AIX 5.3 box? The documentation I've >> found on the web is byzantine at best and it would be fine if the commands >> actually worked, but I keep getting odd error messages and stalled at >> every >> turn. >> >> I've upgrade the GSK so that the server will start with SSL enabled, I >> have >> a virtual host configured, but I have no clue how to tie a specific >> certificate to the VirtualHost. Well, let's say I have clues, but nothing >> is working. Here's the <VirtualHost> stanza I have set up in httpd.conf: >> >> <VirtualHost *:443> >> SSLEnable >> SSLClientAuth None >> SSLServerCert api.client.com >> ServerName api.client.com >> DocumentRoot /usr/www >> <Directory "/usr/www"> >> Order Allow,Deny >> Allow From All >> </Directory> >> ErrorLog logs/api_error.log >> CustomLog logs/api_error.log common >> </VirtualHost> >> >> I've been able to generate a CSR and create a self-signed certificate, and >> it would appear that I've even successfully imported that certificate into >> my key database, as demonstrated by this command: >> >> $ gsk7cmd -cert -details -db /usr/IBMIHS/ssl/client.kdb -label " >> api.client.com" -pw "password" >> >> ...which produces the following output... >> >> Label: api.client.com >> Key Size: 512 >> Version: X509 V1 >> Serial Number: 00 DB 00 41 9A 19 77 7E 9F >> Issued By: api.client.com >> CLIENT >> City, ST, US >> Subject: api.client.com >> CLIENT >> City, ST, US >> Valid From: Saturday, February 16, 2013 6:06:08 PM EST To: Saturday, April >> 17, 2032 7:06:08 PM EDT >> Fingerprint: ... >> Signature Algorithm: 1.2.840.113549.1.1.5 >> Trust Status: enabled >> >> But even though this certificate is in the keyfile (and yes, I have a >> KeyFile directive elsewhere in the httpd.conf file pointing to the >> client.kdb file) I can't seem to associate it to the virtual host. What >> am >> I missing? >> >> (And yes, I'm aware this is not specifically a U2 question but I need this >> to provide web connectivity to a Unidata machine from a Rackspace hosted >> server. So in a way... it sorta is U2 related.) >> >> Help? >> _______________________________________________ >> U2-Users mailing list >> U2-Users@listserver.u2ug.org >> http://listserver.u2ug.org/mailman/listinfo/u2-users >> > > > > -- > John Thompson > -- John Thompson _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
