A digital signature, like all cryptographic algorithm, does not solve problems, it just moves them around.
Take care that signatures are NOT encryption. If someone tried to explain signatures as a kind of encryption, then go find them and hit them in the teeth with a wrench, repeatedly. Tell them that they are unworthy, and I am disappointed with them. This flawed explanation does not work, never worked, and spreads only confusion.
In a signature system, there is a message m, a public key kp, a private key ks, and a signature s. The signature generation algorithm computes s from m and ks. The signature verification algorithm takes m, s and kp, and returns either "true" or "false". When it returns "true", what this means is that whoever owns the public key (i.e. knows the corresponding private key) was involved in the generation of signature s on the specific message m.
The important point is in the key ownership: the signature verification algorithm does not tell you "yep, this is signed by Bob"; it only tells you "yep, this is signed by whoever owns that public key". This guarantees that the signer is really Bob only if you have a way to make sure that the public key you see is really Bob's public key. If Bob simply sent his public key along with the signed message, it would be easy to impersonate Bob by simply saying "hello, I am Bob, here is my public key, and here is my signed message". It would prove nothing at all. The attack here is simple, it is called "lying".
While signatures are useful (indeed, they reduced the problem of verifying the provenance of several messages to the problem of associated a single public key with its owner), they don't magically guarantee ownership out of thin air. This is where Certification Authorities come into play. The CA is an organism whose job is to make sure that Bob really owns his alleged public key; presumably, the CA does that by meeting Bob in person, or some other mechanism of that kind. When the CA has duly verified Bob's ownership of his key, the CA puts Bob's identity (his name) and his public key in a certificate. The CA then signs the certificate.
Alice's machine can then verify the signature on the certificate, thereby making sure that the certificate contents are really from the expected CA. At which point Alice has some guarantee about the fact that the public key she sees in the certificate is really Bob's key, and she can use it to verify signatures which have purportedly been computed by Bob.
At this point you should say: "But how can Alice verify the signature on the certificate by the CA ? She would have to know the CA public key !" And, indeed, the problem has again been moved, to the question of CA key ownership. We can move it yet another time, with another CA. And so on. But it must stop somewhere. That "somewhere" is the root CA. A root CA is a CA whose pubic key you already know, absolutely. That's the magic part. In practice, your computer comes with an operating system that already includes the public key of a hundred or so of root CA, who made a deal with Microsoft to the effect that their public keys are inherently known (and trusted) by all Windows systems.