I got a very similar outcome when I tried to do the exact reverse behaviour to yours, i.e. to redirect from www.domain.name to domain.name only. The Apache error shown in the Apache error_log file was:
Certificate and private key localhost:443:0 from /opt/bitnami/apache2/conf/server.crt and /opt/bitnami/apache2/conf/server.key do not match
AH00016: Configuration Failed
I could verify this mismatch using the openssl utility. Anyway, just the timestamps of these two keys were not logically sequenced.
What struck me was that the initial configuration worked, with the proper certificate CN! And I didn't touch eny of these settings. It's as if server.crt, which was now back to wwW.example.com (literally), had been overwritten.
However...Backing out my changes didn't fix the problem.
The method I used when the problem arose:
To restart Apache I was using sudo /opt/bitnami/ctlscript.sh restart
, as per documentation referenced in one of the comments.
My solution
I edited /opt/bitnami/apache2/conf/bitnami/bitnami.conf
, I deactivated the VH that was pointing referring to the 443 port, including the Listen line. I restarted (started really, since it was down) Apache2, and this time I could observe some threads listening onto port 80.
Bizarrely enough...despite no process seemed to listen to port 443, I was able to request https://domain.name/ perfect! And it had the proper SSL certificate attached to it.
My theory is that bitnami works as an overloading configuration: it supersedes if activated, or lets an above configuration win if not. But I don't know where this "higher level" configuration is actually sitting. Maybe it's related to the CloudFront / Load Balancer configuration? t.b.c.
To this day I don't know what provoked the fact that suddenly, the :443 configuration was pointing to the mock SSL cert was the one being used, just because I added a redirector in the VH, and rolled it back out...