I’ll try to give a bit more explanation. Don’t worry too much if you don’t follow everything and decide you don’t care, the tl;dr is that everything is fine.
SSL certificates are a bit like real world certificates, with a signature on them that proves the contents of the certificate (like who it was issued to and what for) are agreed by the signatory. Instead of being signed with a pen and a unique-ish squiggle by a human they’re signed using a cryptographic hash to turn the contents of the certificate into a number, and then public key cryptography to turn that number into a different number in a way that only someone who knew the associated private key could do, but anyone with the right public key can verify. Public key cryptography is a whole separate subject but you can find Wikipedia article or Youtube videos explaining RSA, the type of public key cryptography you’re using in this case.
But individual SSL certificates still leave you with a problem, you know somebody signed this certificate, but how do you know whether to trust them ? More certificates! Your certificate for www.example.com is issued by Let’s Encrypt, and then Let’s Encrypt has a certificate (which is included in that chain.pem and fullchain.pem if you examined the files on your server) and that proves it was authorised by DST Root CA X3 to issue certificates to other people. This is a different kind of certificate (you can’t use your www.example.com certificate to issue more certificates, just like my 100 metres swimming certificate doesn’t authorise me to drive a bus) but it too is signed in the same way.
It still leaves us with the problem of how we trust DST Root CA X3 in the first place. The diagnostic says “in trust store” and indeed in either an operating system like Windows or Mac OS X, or in a web browser like Firefox, there is a “trust store” which is a collection of certificates, the subjects of those certificates will be trusted by the OS or browser. These are called “roots” because they are at the root of an imaginary tree in which your certificate for www.example.com is one of the leaves.
OK, now, “weak or insecure signature” refers to the line above where it says “SHA1withRSA” and you’ll see the earlier ones all said “SHA256withRSA”. I said signatures are made with a hash algorithm combined with a public key algorithm, and this means the DST Root CA X3 certificate was signed using the SHA1 hash, whereas the others used SHA256. SHA1 is a rather old hash, and experts suspect that it will soon be “broken” affordably, that is, a criminal or government with some money will be able to create things that hash to the same value, which would in turn (if not for countermeasures) mean they could forge working certificates.
So to stay a step ahead, the operating system and browser vendors, “trust store operators” have decided no-one shall use SHA1 to make more certificates and their operating systems (and browsers) will stop trusting the SHA1 signatures on certificates next year.
BUT, the DST Root CA X3 isn’t a certificate they need to trust - they baked it into their operating system or browser as part of the trust store, they know it’s authentic and not forged because they put it there. So this certificate is exempt from the rule, and that’s why it says “but no impact on root certificate” in the diagnostic from SSL Labs.
The root keys don’t “really” need to be inside a certificate at all. But the software processing them deals with a lot of certificates already, and keys aren’t just a single number like “5” they need other information in some format with them, so everybody just transports them as “self-signed certificates” even though we don’t really need them to be signed.