http://mivo.truxoft.com
MIVO!
miva beyond limits

MIVA^®  SECURITY: SSL Miva calls

by Ivo Truxa, 06/23/2000 (updated 10/10/2001)

1. Introduction
2. Shared SSL certificates
• cgi-bin form URL calls
• direct Miva calls
3. Own SSL Certificate
4. Links
5. User Comments

This article tries to give answers to some common questions about calling Miva scripts through SSL (Secure Sockets Layer).

In the following examples I presume using Apache 1.3 on Unix and Miva 3.6, but there should not be great difference to older versions. At the moment of writing I cannot guarantee relevance to future versions.

top

Calling your Miva scripts in the same way as their standard equivalents, just adding https://  in front of the URL often does not work. The reason is that IHPs (Internet Host Providers) mostly use another domain name to serve your documents securely using a common SSL certificate. Often the URL to call your documents looks something like the following example from CI Host and OLM. It can vary at other IHPs:

Therefore people often try to call their Miva scripts like that:

After sending this URL to the secure server it looks for settings in the following precedence:

1. .htaccess in the script directory
2. .htaccess in your root directory
3. Apache configuration on the secure machine

If it finds any MIME type setting for the script in your .htaccess files, it will try to access the respective Miva binary to parse the document. Usually people have something like that in their .htaccess:

Action application/x-httpd-Miva /cgi-bin/miva
AddType application/x-httpd-Miva .mv

This works fine for the standard calls, but it depends on the secure server configuration if it works with https://  too. It will work only in the case that there is a miva binary in the secureMachineRoot/cgi-bin/ too and that there are the right settings in the miva.conf on the secure server. Miva Empresa invoked on the secure machine will look in miva.conf for the settings of <VirtualHost secure server IP> not for your <VirtualHost yourdomain IP> section. The mivaroot (alias to htmlscriptroot) and the stdmodedatadir parameters in the secure <VirtualHost> Miva parameter block must be be properly mapped to the physical locations of your script and data directories (absolute paths).

top

As for now, I did not yet seen an IHP with a correct configuration for this kind of call. Well, I did not check a lot of them yet. Mostly they force you to use the following cgi-bin-form URL, which is quite dangerous and should be definitely disbaled:

https://machinename.site-secure.net/miva?yourdomain/script.mv

https://machinename.site-secure.net/smiva?yourdomain/script.mv

top

In the case you have still problems to call your scripts securely and your IHP is not willing or able to help you, you may want to take the changes in your hands. Also if you prefer using direct (short) URLs than the dangerous long cgi-form ones (cgi-bin/miva?path/script.mv), then you need to help yourself.

NOTE: if your can access your secure documents with the form
https://yourdomain.securedomain.ext/ instead of https://yourmachine.securedomain.ext/yourdomain/, then you can skip the following description of .htaccess configuration. All you need to do in your case, is setting the right paths for both VirtualHosts <VirtualHost yourdomain.com> and <VirtualHost yourdomain.securedomain.ext> in the miva configuration file.

One way is to split your scripts in two groups - secure and standard. The most easy solution is to keep them in separate directories and to make a different .htaccess in each of that directories. For example:

.htacces in standard directory:

(the path to the miva binary has to be relative from your web root!)

.htacces in secure directory:

(the path to the miva binary has to be relative from the secure machine web root!)

With these settings, both secure and standard calls find your miva binary fine. You can also consider using Apache directives <Directory> or even <Files> if you want to mix secure and insecure scripts in a directory:

<Directory somedir/somesubdir>
AddType application/x-httpd-Miva .mv
Action application/x-httpd-Miva /yourdomain/cgi-bin/miva
</Directory>

or

<Files a?bc*.*>
AddType application/x-httpd-Miva .mv
Action application/x-httpd-Miva /yourdomain/cgi-bin/miva
</Files>

See the Apache documentation for details on both directives and other similar ones.

NOTE: please keep on mind that even if the standard server is for example Apache 1.3.4, the secure server can be an older version for example Apache 1.2 (that is the case at CI Host or OLM at these days). If you use some newer directive that works with your standard documents, you may get '500' error with secure URLs. This is the case for example with FilesMatch or DirectoryMatch!

There are still other ways to go! For example you can choose different extensions for secure and standard Miva scripts:

Action application/x-httpd-Miva /cgi-bin/miva
Action application/x-httpd-MivaSec /yourdomain/cgi-bin/miva
AddType application/x-httpd-Miva .mv
AddType application/x-httpd-MivaSec .mvs

Well, as for the MIME type settings, you have enough choices to select the best suiting for you. Though that is not all. Now you need to set your Miva configuration file. There are probably just very few people whose miva.conf is set correctly at the server root for both standard and secure calls. If you are not able to bring your IHP to change the setting, you have to do it yourself.

Please read the articles art0006.htm and art0002.htm for details. Simply told, you just need to copy the binary from your cgi-bin to another and to create a configuration file of the same name as the binary: for example copy miva to mivo and create mivo.conf

If, for whatever reason, you need to keep the same name 'miva', you need to make a simple patch of the binary.

Now you just need to put all necessary parameters to the mivo.conf. Note that you have to use the VirtualHost directive to make different settings for your standard and secure documents. For example:

htmlscriptdefault=index.mv
redirectonly=yes
validextensions=.mv,.hts,.htm,.html
globaltimeout=90
mailtimeout=20
calltimeout=60
usecookies=yes
loglevel=0 

<VirtualHost 111.122.133.144>   <-- your standard IP address
mivaroot=/absolute_path_to_your_script_dir
stdmodedatadir=/absolute_path_to_your_data_dir        
</VirtualHost>

<VirtualHost 155.166.177.188>  <-- IP address of your secure server
mivaroot=/absolutePathToYourScriptDirFromTheSecureServer
stdmodedatadir=/absolutePathToYourDataDirFromTheSecureServer
</VirtualHost>

You can also use the full domain names instead of IP addresses. You can also put other parameters in the virtual host definition block: sitevars, logfile, cookies, timeouts, etc. If you are unsure of your right path mapping, and can run Miva scripts at least with the long cgi-bin formed URL, you may be able to display the path with the following command:
<MvEVAL EXPR="{s.path_translated}">

top

If you have own SSL certificate and a machine that serves both secure and standard documents, the problems should not be as complicated as with the described redirected secure server. As for now I am not aware of any specific problems. Please feel free to contact me if you find any.

top

Miva Empresa installation and configuration manuals:

http://www.miva.com/docs/empresa/
http://www.miva.com/docs/installdocs/instunix_emp_v364_r1.pdf
http://www.miva.com/docs/empresa/emp_unix_config.pdf

SSL (Secure Sockets Layer):

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
http://www.apache-ssl.org/
http://www.openssl.org/
http://www2.psy.uq.edu.au/~ftp/Crypto/

If you use Apache server, get more details on possibilities of .htacces configuration file in the Apache documentation

top

Miva and some other terms used on this page are registerd trademarks of the Miva Corporation
copyright  truXoft  © 1997-2010