If you aren't concerned about the user being prompted, then you intercept most HTTPS connections by proxying them. Instead of allowing the user to directly connect to the site they've requested, you connect them to a intermediary you control, and then use it to connect out to the to site that they've requested. This way the client's HTTPS session is terminating on your box, with your SSL cert that you own the private key for, and thus you decrypt the client-side traffic, and since it's your proxy that is then making the connection out to the server they actually wanted to talk to, your proxy is now the client for that SSL connection, and you have full access to the traffic from that side as well.
This will prompt the user because of course your SSL cert, the one on their server the users are connecting to, will not be a valid cert for the sites they're actually trying to access, so client apps will (or should at least) view this as an attack and warn the users not to trust the connection. As P4cK3tHunt3R mentioned, you can avoid the warning by installing your cert as a trusted root on the client devices, in which case they will no longer be able to discern (generally speaking) that the cert is not in fact valid and trusted for the site they're trying to connect to.
Aside from proxying, there are other ways to downgrade connections as an active MitM, such as SSLStrip, which will work in some cases, and not in others.
In some cases, proxying works even better than advertised, with mobile apps particularly, which are notorious for ignoring certificate warnings and happily accepting untrusted certs without bothering to inform the user than anything is amiss. In other cases, it won't work at all, due to practices like certificate pinning where a browser or other application only trusts specific certificates, and will refuse to accept your certificate, even if it would otherwise be valid and trusted.
