I've setup froxlor based on a well functioning LAMP stack enabled SSL witch certbot/letsenrypt. 
Manual vhosts setup followed by certbot SSL procedure works well.
mariadb & phpmyadmin access all fine. 
froxlor setup with tarball approach worked well. 
Also certificate creation through froxlor  works well ( double checked with php /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug ). 

So far all fine with the exception that domains assigned in froxlor are falling back to the default.
Forum researches pointed me to the following possible root cases, which I've verfied and can be excluded in my case: 

- Missing IPv6 entry: Not the case, my provider doesn't provide yet IPv6 addresses, only IPv4
- DNS issues: Can be excluded all fine with DNS, the same domain was already used earlier in the past for another server with same LAMP-Stack/certbot-lets
 setup with same public IP.
 
apache error.log tells me: 
"No matching SSL virtual host for servername my-domain.com found (using default/first virtual host)"
also, 'certbot certificates' shows only the initial SSL domains created at the time with certbot, not the ones coming from froxlor

From this post I got the hint, first to assign a new domain without SSL and later on apply the SSL flag. 
Didn't help in my case. 

This brings me to the question: 
Would it be better to not use certbot nor for server preparation as well as afterwards on the running froxlor server?
Any other recommendations to solve or further debug the issue?

Many thanks for any hint!

Thomas
 

7 minutes ago, Thomas Oettli said:

Would it be better to not use certbot nor for server preparation as well as afterwards on the running froxlor server?

froxlor uses acme.sh and interacts with it, i would recommend using acme.sh itself too for manual certificates instead of installing other tools.

7 minutes ago, Thomas Oettli said:

Any other recommendations to solve or further debug the issue?

Yes:
1) what's the server-IP? output of "ip a s" might be helpful
2) show us the generated vhost configuration file of a domain that's not working correctly
3) show us the domain settings in froxlor of such a domain
 

Thanks for this very fast answer! Here the requested infos: 

1) 'ip a s' output (server is accessed through DMZ config on the router from outside through public ip     51.154.6.40 - showing the internal LAN IP might already the issue):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:11:32:28:55:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.83/24 brd 192.168.2.255 scope global dynamic ens3
       valid_lft 1205315sec preferred_lft 1205315sec
    inet6 fe80::11:32ff:fe28:55e3/64 scope link
       valid_lft forever preferred_lft forever

2) confs, generated by froxlor for oc-example-02.com

35_froxlor_normal_vhost_oc-example-02.com.conf: 

---
35_froxlor_ssl_vhost_oc-example-02.com.conf:

---
3) snapshot froxlor domain config: 

Okay, that's the issue. The webserver cannot listen on an IP Address that is not configured on the server. You will need to exchange 51.154.6.40 with 192.168.2.83 in froxlor (you can use the install/scripts/switch-server-ip.php helper script for that).

Then, the webserver will create vhosts with "<VirtualHost 192.168.2.83>...", will recognize them and point to the correct location

Also, in order for let's encrypt to work properly, you will need to disable the domain dns validation as it won't be able to validate private ip address ranges (settings -> ssl -> Validate DNS of domains when using Let's Encrypt, at the bottom)

Thanks a lot!  A first try wasn't successful. However, I've to go through once again step by step. I'll come back, as soon as  I have clear, reproducible results. So far, a setup with same installation procedure on a rent VPS where 'ip a s' returns the public IP doesn't have any issues like this. It's anyway for dev/testing purposes. Priority is now to set up my production froxlor environment on my hosted froxlor subscription on froxlor.com. There, I don't have this kind of issues anyway.