OK, there is something wrong with using self-signed certificates: you can only use them for 1:1 connections.
If a computer X has to communicate with 10 other computers, they all must include its self-signed certificate in their so-called "truststore" (the database of all certificates you want to use); or X must include 10 self-signed certificates from other hosts in its truststore; or another distribution, depending on who starts the contact. So it's useful if they all use certificates that are signed by the same CA: then they only need to include the CA's (self-signed) certificate in their truststore. The authentication of their own certificates can then be checked by the others and they can communicate securely.
There is a misunderstanding that I have encountered several times on how certificates and truststores work. Some people think it is sufficient to add the public certificate of some partner in a truststore, to limit connections to only that partner. However then the trust chain is incomplete, and the PKI software will refuse to set up a TLS connection. You will have to also add the public certificates of all intermediate CA's up to the root CA into your truststore. But then your PKI software will accept any certificate signed by that CA. The exclusion will only work if the single partner certificate is a self-signed certificate, as discussed above. This demonstrates that PKI only handles confidentiality and integrity and, to a limited extent, authentication. For an exclusive connection you will have to inspect the certificate, filter for a specific identity, and make an explicit decision on what you will exchange with this partner. See Authentication and Authorization further on.
It is insane to use certificates signed by a public Certification Authority like Verisign to secure connections between computers on your own Intranet. Then you need to send Verisign a CSR to confirm that your computer A is yours, and you will then receive a certificate that will allow your computer B to determine that your computer A is yours, and Verisign is getting rich laughing. You can do that yourself. Always use your own CA on your Intranet.
In addition, certificates have a limited duration of validity - typically 1 or 2 years. The reason is preventive maintenance. Private keys are bits that on a computer, and anyone who has access can copy them and use them elsewhere. Worse, that is often necessary (see Pitfall 5: copying private key.). If your private key is stolen or cracked, you lost your privacy and integrity, and often you do not even know. Just in case, it is wise to replace certificates regularly.
I have seen administrators have the habit of re-submitting the old Certificate Signing Request to the CA when a certificate expires; they get a new certificate, which they then install with the existing private key. They do not have to create a new keypair. But compare that with the maintenance of an airplane: instead of preventively replacing all old nuts and bolts with new ones, we just turn the old ones back in; whether they will break tomorrow because of fatigue we do not know. The reason for this shortcut is that the entire Key Management Procedure is sometimes as tedious as if you have to cut the new nuts and bolts yourself. Then you choose the easy way.
On the other hand, the limited duration of certificates is unnecessary: as long as private keys are not compromised, you can safely use them and no new certificates are required. If your certificate expires, you can reuse the old CSR as well. However the point is that you are not sure whether your private key has been compromised over time or not.