I would recommend investigate some low-cost hosting, since what you are detailing isn't generally possible with port 80 blocked without a third-party involved anyway.
This isn't mandatory - you can still host the site - but you will almost certainly be using one of the two options below.
Using A DNS Service With A Separate Dynamic DNS Provider Subdomain
On the question of redirecting HTTP requests to HTTPS, from the details of your post, I am assuming your DNS provider for example.com facilitates this. Assuming you wish to redirect these to https://powe.ddns.net I would do so directly via URL Redirection:
www.example.com --> https://powe.ddns.net
example.com --> https://powe.ddns.net
Further HTTPS redirection should be unnecessary.
Using Domains Directly With A Dynamic DNS Provider
Dynamic DNS services which allocate subdomains are useful, but you may wish to investigate a DNS provider (either your current registrar or a third-party) that has a dynamic DNS client and allows you to use your domain (e.g. https://example.com) directly with those services.
While normally possible with port 80 available, HTTP to HTTPS redirection (e.g. http://example.com --> https://example.com) in your case isn't possible without third-party intervention, since URL redirection records and basic DNS A records will create an issue regarding the IP address(es) for a given entry (so this would cut-off using non-HTTPS URLs).
UPDATE: Per OPs own accepted answer, apparently CloudFlare will intercept requests for port 80 and redirect them to port 443. They also apparently have a dynamic DNS client.
Regardless of using CloudFlare, it's possible to still use the HTTPS versions of a domain normally either way.
Regarding redirection of https://example.com to https://www.example.com without CloudFlare, the solution would be to point both at your server IP directly and sort non-www requests and www requests on the server itself.
If you haven't already done so, simply create two A records as normal directly pointing the correct IP of your server e.g.
example.com. IN A 99.100.101.102
www IN A 99.100.101.102
and use HTTPS to access them. Consult your DNS provider on exact formats for these records.
Note that you will likely need to make any Dynamic DNS client aware that you wish to update the IP for both these entries.
Next, in Apache, redirect https://example.com to https://www.example.com. Again, for simplicity, you can use:
Redirect / https://www.example.com
inside an HTTPS virtual host for https://example.com, although you may want to use other redirect options (i.e. 301, 302), especially for SEO purposes.
Certificates
As a brief caveat about certificates, remember that https://www.example.com is a subdomain of https://example.com and if you want to work with both without a browser error, you need either:
If you need free certificates that aren't self-signed, a possible choice is one issued by Let's Encrypt. Their website doesn't have a direct interface for certificate requests or management but ZeroSSL has a both a web interface and command-line client (both as a Perl script and Windows binary). There are other clients available too.
The only drawbacks to Let's Encrypt certificates is they are short (only 90 days) and they currently do not issue wild card certificates. There are some rate limits on certificate issuance but they are currently fairly reasonable.
In-Browser URLs
While it is possible to "mask" URLs so they do not change at all in the browser address bar, this often requires either a separate server loading content in a frame or some creative uses of mod_rewrite which may or may not work depending on a number of factors.
In the case of HTTPS, masking potentially can undermine the HTTPS working as intended (primarily for security). In short, if you can be happy with minimal changes to the URL (e.g. http:// becoming https:// or possibly redirecting https://example.com to https://www.example.com server side), I would use choose that route, using example.com directly with a Dynamic DNS provider as outlined above.
SEO Considerations
Note that both the www and non-www versions of your site will likely be considered separate domains with duplicate content for SEO purposes (indexing with search engines). So you may want to take steps accordingly if you want your content indexed correctly e.g. by Google)
The kind of response expected by applications when connecting to an HTTP server is very different from the kind of response given by an HTTPS server. Thus, simply redirecting HTTP requests to HTTPS via port redirection is never going to work. My recommendation is to rent a cheap VPS so you can host your Web contents properly without having to resort to hacks. If you don't want to go this route, you will have to tell your potential visitors to access your Web server via HTTPS. Their Web browsers will then automatically send the requests via port 443 by default. – Larssend – 2017-07-15T05:14:06.240
Yeah, I noticed that when using HSTS it forces https://*** which is great for me! What I wanted to do is have people who visit the site go to port 80 and be redirected to the https:// version of the site. I know a reverse proxy can do what DNS does just with ports instead of IP addresses, so it would work, but I don't know of any "reverse proxy providers."
– BoomBoomPowe – 2017-08-04T16:23:45.130