Le plus simple, c'est de configurer tes navigateurs (Internet Explorer en active directory) pour qu'ils ne bronchent pas si le certif n'est pas bon.
Par pitié, ne jamais proposer de telles solutions, même si elles existent !
Pour en revenir au sujet, faut bien se rappeler HTTPS est un élèment fondamental de la sécurité du Web, et il faut peut-être en mesurer les conséquences avant de tout casser sur son propre réseau. Lorsqu'un proxy intercepte et déchiffre un flux HTTPS (et le modifie potentiellement), l'intégrité et le chaîne de confiance avec l'hôte originel sont rompues.
Par ailleurs, il y a de très, très fortes chances que ton proxy affaiblisse la sécurité, soit en ne validant pas correctement les certificats (coucou les antivirus), soit en ne supportant que des versions anciennes des protocoles (cf :
https://jhalderm.com/pub/papers/interception-ndss17.pdf)
C'est pour ça qu'ajourd'hui,
on ne recommande pas d'intercepter les flux HTTPS, explications du CERT/CC (
https://www.us-cert.gov/ncas/alerts/TA17-075A), et même de l'ANSSI (
https://www.ssi.gouv.fr/administration/guide/recommandations-de-securite-concernant-lanalyse-des-flux-https/), qui recommande de bien mesurer les risques introduits par de telles pratiques.
Bref, je ne sais pas quel est exactement le contexte ici, mais avant de me lancer dans la décryption du HTTPS, je commencerais par
mesurer le trafic sortant HTTP et HTTPS, puis
mettre en place un bon vieux proxy+cache HTTP, sans déchiffrement du HTTPS, et observer les gains.
C'est certain que tous les grands du Web (Facebook, Google, ...) sont en HTTPS et ont "de grosses apps", avec beaucoup d'assets statiques, mais
ils gèrent aussi très bien les règles de cache au niveau des clients. Et le contenu "par utilisateur" ne bénéficierait pas d'un hypothétique proxy-cache HTTPS.