@David Hammen's answer is very well put, though not exactly what I'd have said. I agree that Verification answers "Did we built this one correctly?". Anything produced by a process can be Verified. Manufacturing involves constant verification that the thing being produced has been produced correctly.
He then defines Validation, which we agree is different, as "Did we build the right thing?" I would say that Validation moves in the opposite direction, to exhaustively confirming precisely correct functioning of a design. More like "Objectively demonstrate that the solution is correctly designed". The right grades of bolts, the right sizes of internal variables. The pieces are up to the job.
David's Validate, "Did we build the right thing?" is a high-level question that isn't something you can run against the daily build, thumbs up or thumbs down. Its a judgement of the requirements and to a lesser extent, the design. Its not a sensible question addressed to a text box on a screen or a parameter in an API. Not sure what the one-word name is for requirement correctness, maybe Requirement Validation. Exhaustively proving that the requirements correspond to the needs of the end user.
By contrast, my definition for Validate is proof of correctness of a design, objective tests that show the pieces selected will do the job. The Ariane IV software that was unsuitable for Ariane V would fail here, because Ariane IV had a limited range of angle-rate changes. The code was optimized for this limited range, and Ariane V was capable of a larger range of angle rates, which caused the overflow. When both onboard computers crashed on overflow, and did it again after auto-reboot, the destruct system was triggered.
As Dykstra said, "Premature optimization is the root of all evil."
In my definitions, the requirements are presumed to be correct and accepted, validated by Requirement testing. Design or Code Validation proves that the design, perhaps a bit of the implementation, is correct. It still has to be executed correctly, but confirming that is Verification, testing based on accepted Requirements and an accepted Design.
You'll note that this hews painfully close to the Waterfall model of development, which seems harmful if believed to describe complex systems. None the less, Requirements are different than Design and Code is a third thing entirely. I guess my plea is that the elements in the Waterfall are useful descriptions, but that 'complete' is misleading, so I've changed it to 'accepted' which suggests contingency and mutability.