Is there a way to make sure my government does not swap out SSL certificates?

If your adversary is a powerful nation-state threat actor, web PKI will not protect you.

Nothing is preventing them from issuing their own certificate. In fact, many governments run their own certificate authorities, such as the US FPKI and affiliates. See a list of CAs currently trusted by Firefox:

• Government of France
• Government of Hong Kong (SAR), Hongkong Post
• Government of Japan, Ministry of Internal Affairs and Communications
• Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
• Government of Spain (CAV), Izenpe S.A.
• Government of The Netherlands, PKIoverheid
• Government of Taiwan, Government Root Certification Authority (GRCA)
• Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)

While Firefox currently refuses to trust the US FPKI, it still trusts many other government-run CAs, and a sophisticated nation-state actor absolutely has access to some existing, commercial CAs. Chrome, Internet Explorer, and Edge use the system trust store which, for Windows, does include many government certificate authorities, including the US FPKI. Any of these could be used to sign a valid certificate for any website and your browser would happily trust them without batting an eye.

While the new and experimental standard for Certificate Transparency (CT) helps reduce the impact of mistakenly-issued certificates, it does not protect against a dedicated attacker who controls a malicious CA. Once it has seen greater adoption it may, however, make it easier to spot malicious or misbehaving CAs after a short period of time, but it will not prevent the attack immediately as it is performed.

Some browsers use certificate pinning where important and high-profile domains are validated against a hardcoded list of permitted certificate authorities. Signing a fraudulent certificate for those domains would require compromising the CA that they currently use. Unfortunately, this only applies to a small handful of domains and does not protect the web at large.

A partial solution would be to refuse to trust a domain without the .gov TLD whose certificate was issued by a government CA, which could be implemented client-side, but it would likely have little real-world impact. An adversarial government is not going to sign a malicious website with a state-run CA, since that would immediately attribute the attack to them. Rather, they would exploit covert relationships with existing CAs to trick them or force them into signing the certificate. CT, as mentioned in the previous paragraph, would detect this and the attack would be quickly noticed, but it does not prevent it.

Even if you have the original CA certificates the browser/OS might be modified to not properly check certificates. Or the browser/OS might be backdoored so that the plain data can be extracted directly from the application before encryption or after decryption. And such critical modifications or changes in the behavior might also be caused by the hardware you are using.

This means essentially you are asking how to make sure that the system you use (hardware, OS, software, configuration ...) has only the functionality you expect, i.e. has only the functionality intended by the vendor and developers (no backdoors or similar added later) and that this functionality does not include anything which can be used against you (no backdoors by vendor/developer but also no critical bugs which might be used as backdoor).

Unfortunately there is no mechanism to make fully sure that your system behaves like this. Ultimately it boils down how much you can trust the delivery chain both in terms of explicit backdoors but also regarding bugs (inadvertent backdoors). Delivery chain means how much you can trust the sources where you got your hardware and software from (vendors, downloads from the internet...) and also how the hardware and software got protected against tampering during transport from the source. And these sources usually use third party components too which means the question of how much the delivery chain can be trusted must be extended further.

There are a few ways which can help to trust the delivery chain but full trust is not possible. One way is to actually know your delivery chain in the first place and keep it small enough so that you can actually audit it. This also includes to have less complex systems since these allow for a smaller and more easy to audit delivery chain. While this might be possible for some governments or really large companies which have to fear targeted attacks, it is practically impossible for normal end users. These might try to reduce the risk by buying only from trusted vendors though (maybe abroad if you don't trust local vendors) and to minimize what is downloaded from the internet and to make sure it gets always loaded via a secure transport. One might also try to compare critical parts (like local CA certificates or the CA used for a specific connection) with others.

There are also mechanism like secure boot or certificate pinning which help to prevent or detect smaller modifications but might be simply bypassed by a more sophisticated attacker (government agencies) which might replace/disable the relevant checks if he controls enough of the delivery chain.

At the end an unsophisticated end user does not have much chance to distinguish between normal and abnormal system behavior since he does not have enough detail what a normal system behavior should look like in the first place. But assuming that attacks like replacing CA certificates or MITM using government controlled (and browser-trusted) CA will not target only such unsophisticated users but will be more widespread it is likely that some more paranoid and also knowledgeable user will be affected and will detect the attack and warn others.

It is also likely that the attacker will not control enough of the delivery chain, especially if more or less free access to the internet is possible (i.e. mostly free access apart from some explicit blacklisting). In this case users might download software which has added protection - like the built-in SSL-pinnings for critical domains in browsers like Chrome or Firefox. On the other hand paranoid users can also be tricked into downloading software which claims to protect their privacy but instead is a espionage trojan.

Yes. Check the certificate's issuing CA and its fingerprint and/or entire public key, which you can find by viewing the certificate details in your browser. Compare these against the values seen by another person or another computer outside of the domain of the relevant government's control. You could do this with a cheap vps hosted in another country using command line tools to make the TLS connection and dump the certificate info. You can also use Certificate Transparency logs to see if you're getting a different certificate from what's being presented to other users.