I have a fresh install of CentOS 7.2.1511, with only VirtualBox loaded as an extra package under a pretty basic server setup with the GUI for occasional desktop use to open/run VirtualBox. The base server itself is 'sub.domain.local', at 192.168.0.111 on a local/private network.
Through Webmin/Virtualmin I have enabled SSL on every domain I've created so far to use self-signed certs. This is a dev server, so all 3 sites currently created have a ".local" TLD. I have modified my Win7 host file to point to the server's IP for every one of these, so I don't have any issue using the non-standard TLD. Likewise I can access it directly via it's IP number.
Browsing to any of these as non-secured pages will render the expected page output for each one. The 1st domain also has phpMyAdmin installed in a subdirectory and it's running correctly (without aliases or anything else to create other issues).
However, using https to browse each one shows unexpected results...
I have deleted and redone these domains and their contents 3 seperate times using webmin/virtualmin only, so no hand editing of any files. Each time I've ended up with the same outcome. I did have to insert an AddHandler in php.conf for php to function properly, but that shouldn't, I assume, have any bearing on SSL.
Looking in etc/httpd/conf/httpd.conf for any VirtualHost 192.168.0.111:443 lines... there is no entry for the 1st domain, only the 2nd and 3rd. I'm guessing that might be the issue. I could probably add something, but that won't fix any overall bugs if it's needed for virtualmin to do it on its own.
Perhaps the phpmyadmin installer did not insert a rewrite rule in the https section of 2nd virtual server's web configuration. You should be able to cut and paste that rule if you can recognize it.
And check to see if your "2nd server" has been set as "default server" somehow instead of the first one you created. That would explain why it's the choice when you use only ip address.
Also take into account whether your router properly handles "NAT redirect" from "external IP" (also known by a few other terms). If it doesn't, then you need to hard-code your domain names in HOSTS pointing to the internal IP address of the web server.
I'm not aware of any Apache-owned config files that phpmyadmin might have write access to in order to modify web/ssl access to non-phpmyadmin pages. If that is a possibility, then I'm not sure what to look for or change.
I started using Virtualmin/Webmin way back when CentOS was v4/v5 I think. In all that time I've always set up the 1st virtual domain as the base hosting/controlling domain. I've never even looked if/where the virtual default was or what it was set to point to. The server itself (where WM/VM was installed) had always been the sub.maindomain.com, with the maindomain.com the first virtual I added. It was no different this time, so I've never consciously chosen anything - just added things in the logical order. Now that I know there is a default and looked for it... it is, in fact, set as the 1st. I presumed it would be, so it's not pointing to the 2nd or 3rd.
This server isn't a new one, and it was running the last version of VM/WM on CentOS 6 prior to a reformat and fresh load of v7. The same virtual setups I outlined earlier are exactly the same now as they were on the previous install, and the working hosts file on my windows machines should work exactly the same to reach the new server. I wish it were that simple.
Having a boat load of issues with the VM/WM upgrades of late and them gumming up my previous setup is what prompted me to redo this server. I've done this setup numerous times on numerous servers - both local dev and internet production machines - and I've never come across all the issues I've run into since these last major upgrade changes were rolled out.
At any rate.... I attempted to create a completly new
VirtualHost 192.168.0.111:443section for the 1st domain by copying/modyfying the same section for domain#2 with proper paths and home directory entries.I failed, with: Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
Using the journalctl -xe command provided nothing detailed at all - but I did get:
xxxxxxx]# systemctl status httpd.service
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2016-04-21 16:12:22 EDT; 4min 9s ago
Process: 27409 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited, status=1/FAILURE)
Process: 2530 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
Process: 27407 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 27407 (code=exited, status=1/FAILURE)
Apr 21 16:12:22 rtbase.humantextures.local systemd[1]: Starting The Apache HTTP Server...
Apr 21 16:12:22 rtbase.humantextures.local httpd[27407]: AH00526: Syntax error on line 468 of /etc/httpd/conf/httpd.conf:
Apr 21 16:12:22 rtbase.humantextures.local httpd[27407]: SSLCertificateFile: file '/home/humantex/ssl.cert' does not exist or is empty
Apr 21 16:12:22 rtbase.humantextures.local systemd[1]: httpd.service: main process exited, code=exited, status=1/FAILURE
Apr 21 16:12:22 rtbase.humantextures.local kill[27409]: kill: cannot find process ""
Apr 21 16:12:22 rtbase.humantextures.local systemd[1]: httpd.service: control process exited, code=exited status=1
Apr 21 16:12:22 rtbase.humantextures.local systemd[1]: Failed to start The Apache HTTP Server.
Apr 21 16:12:22 rtbase.humantextures.local systemd[1]: Unit httpd.service entered failed state.
Apr 21 16:12:22 rtbase.humantextures.local systemd[1]: httpd.service failed.
The 'rtbase....' domain is the base server (running VM/WM), with 'humantex' being the 1st virtual server created. It clearly fails since the is no valid SSL cert found for the entire domain. VM never created one when it ran the setup script for the 1st domain. If there's no cert - Apache will not run with incorrect directives in it's config for any of it's served domains - not just the 1st one. Removing my added section lets the server process restart.
Obviously there's an issue with VM's scripts for the 1st domain being created. I have certs in place for #2 and #3 - and they both work as expected. I suppose I can try to trick VM by creating a new domain and later selecting it as the default - then - delete the original, re-install phpmyadmin, and see what happens. All of these steps may get me where I need to be, but '...there be some bugs in thaere somewhere'. I can't imagine this is how it's supposed to be working.
All in all, there was no valid cert created, and no ':443' section for the VirtualHost configuration was added for Apache to use. I'm hoping those are the only 2 issues.
If "Enable SSL website" (under Edit Virtual Server) was checked when this virtual server was created, or has been checked since, then VM will have inserted the https container and generated/found a self-signed cert to point at in it. The server will then never be started or restarted with invalid directives. Adding the https container is practically all you need to do to enable SSL. It sounds like you've done this somehow without letting VM know or having a cert in place when you restarted the server. Visit Edit Virtual Server and snap open the bottom section to verify the SSL Website box is checked. You can install another cert or make tweaks after that.
AFAIK, you're only missing the https phpmyadmin directive (to make the magic url work) which you will find in the http container, and I would paste just that into the https container lower down. The phpmyadmin script was perhaps run before you enabled SSL so you just need to tweak that one bit. Or remove phpmyadmin and re-install it after SSL Website is established?
I toggled/saved the Enable SSL tickbox a couple of times on the 1st domain and ended up with a cert being created. SSL browsing works correctly now for the 3 domains, but there's still the same behavior as before when trying it for the '.111' IP. Since I don't typically have any need to use that base IP - ssl or otherwise - I'm not going to quibble and quit while I'm ahead.