Of course, if the customer doesn't have IBM support, then you might want to try the open source stuff on AIX.
You can find a lot of good "pre-compiled' packages here (they plug right into the AIX package manager) http://pware.hvcc.edu/ They claim that their AIX 6 stuff works on 7 http://pware.hvcc.edu/downloads.html On Mon, Feb 18, 2013 at 8:22 AM, John Thompson <jthompson...@gmail.com>wrote: > 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 > -- John Thompson _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
