OK.  I have an answer. As far as I can tell, the Dell OMSA interface itself does not work for importing intermediate certificates (returns an error) and can't be used to create a useful CSR (signing request) because you can't specify your own institutional parameters. Our CA would not authenticate the CSR request generated by the Dell OMSA interface, even if it would import new certificates (which it appears to fail at). The easiest approach is to generate a CSR in Windows IIS, receive the authenticated certificate back from your CA, then export everything to a .pfx file (private key, end-entity certificate, intermediate and root certificates, extended attributes). Use IBM's tool called keyman (download from www.ibm.com/developerworks).  Use the Windows version. This can convert a .pfx file into an apache keystore in 3 easy steps.  1. Create a new keystore 2. Import the .pfx file 3.save the keystore. Hints on the internet suggest keeping all the passwords the same-- pfx export, keystore, key, etc. Edit the server.xml file in the apache server to use your new passwords. Only downside is that your password will be text readable in the server.xml file.  In the original server.xml file Dell used system or java tools to hide the passwords.
My university is requiring me to replace the Dell SSL certificate in OMSA with a certificate from a CA.  We are using InCommon. I generated a certificate request using Microsoft IIS,.  InCommon generated the certificate and  sent me back links to a variety of formats.
replace the SSL certificate in Dell OMSA 7.2