The first error was due to your trying to 'read' (and verify) a non-existent file.
The second would seem to not be an error, but a 'proper' failure to verify.
What the message actually says it that it cannot find the CA that issued the cert you are testing, and so cannot validate the chain (which would generally be, at minimum issuing CA > your cert).
SSLeay demo server line in your second output would tend to indicate one reason for this is that indeed, you just generated a new CA.
It also looks like you are trying to validate your own CA cert, which is a little redundant - but if you really want to do that, you should run:
openssl verify -CAfile cacert.pem cacert.pem
A more useful/practical example would be validating a (hopefully) known-good cert. Not sure if you can pipe on Windows, but on Linux, you could do:
openssl s_client -connect google.com:443 </dev/null | openssl verify
If you want to see the cert, you can run:
openssl s_client -connect google.com:443 </dev/null | openssl x509 -text
I think you might want to spend a bit of time reading up on how PKI works: generally, a PKI is built when a 'trusted' entity (a Certificate Authority) issues a certificate for another entity - it basically vouches for that other entity (which can be an organisation, a server, a user, etc) being who it claims to be.
So validating/verifying a cert involves the following (grossly simplified explanation coming up):
- from your end-user cert (i.e. the cert used on the domain you are checking - user here is whatever is making use of the cert, not necessarily a human), the Issuer is checked, and the Issuer's public key is also extract (for comparison against known keys for that issuer).
- you could then check first that your end-user cert is properly signed (i.e. the signature contained in the cert is signed by the private key linked to the Issuer's public key, which is included in the cert)
- you could then validate the Issuer's cert, either by checking a list of known-good certs (which is what the OS cert store does), or by repeating the previous two steps if the Issuer has been issued its cert by some other entity.
At some point, you end up at a self-signed cert belonging to an entity such as Verisign/LetsEncrypt/YourCAHere, which is the root of the chain of trust the PKI reflects.