X509 certificate are, basically, made of several kind of information:
- The certificate declarative data which includes everything that the certificates claims about the key owner (mostly what you find in the certificate subject fields but also commonly additional OIDs like )
- The certificate scoping data (for instance: key usage, validity period, etc.)
- The public half of the key pair associated with the certificate.
- The certificate trust chain information (who guarantee that the declarative and scoping data is correct) and revocation data
- Some technical fields (which algorythm is used, what's the certificate serial number, etc.)
You can put anything you want in both the declarative and scoping data and you can control what's in the technical fields (mostly) as long as your CA accepts to validate your cert as you submit it (or as long as you're using self-signed certificates).
The public key part of the certificate is dictated by whatever key algorythm you decided to use. You could use the same key for all your certificates although I wouldn't suggest you do so: there is no valid reason to do so in practice and it could threaten the security of the whole system depending on how the keys are used.
Finally, the trust information includes mostly the issuer reference (which you mostly can decide or, at least, know in advance in most case) and the digital signature of the whole certificate (which you have no way of knowing or control over). Using a self-signed certificate would not help you, in this case, since the only way for the two signature to be 100% identical would be for every part of the signature data to be identical as well: you might as well make a copy of the original certificate instead of signing it twice.
The good news, however, is that while you shouldn't use the same key for several certificate, you do not have to. You can simply create your own CA and have your application verify all certificates against that CA root: that will allow all your users to verify the keys you're distributing - including future keys - while not requiring your to weakening the infrastructure thing by reusing a fixed set of keys.
Pinning the certificate authority - instead of the leaf certificate - is a bit more complex to implement but it's also more flexible and allow for more complex usage scenarii.