Googling I saw several lectures saying that it is possible to sign using digital certificates. I am confused about that, because according to my knowledge it is possible to sign only using the private key, where digital certificates are used during the signature process?
Just a matter of imprecise language that should be understood by everyone involved.
You sign using the private key that only you have. The public key is not used, and the certificate is not used. In fact, maybe there is no certificate using the public key. The verifier verifies the signature using the public key, the certificate is not used. But the public key is just a number (or two numbers). It is inconvenient to handle the bare numbers. So often the public key is carried around with some metadata that says what the public key is for. That is a certificate.
Maybe it just says "juaninf's public key" and is self-signed (has a signature attached made using the private key matching the public key of itself).
Maybe at work it has a note signed by your boss that says "This is the public key of juaninf, I hired him to work for me on 2019-06-23, I am the manager of department D at corporation C, here is a signature from the CEO of corporation C attesting to this fact". And the automatic doors at the building can test this. And your private key is in an unclonable smart card.
If you click on the lock next to the URL in your browser, you can see the TLS certificate for the site. In the certificate, you can see the public key. You can see the certificate, therefore you have the certificate. But you do not have the matching private key. So you can't create a new signature for the public key in the certificate. So you can't do MitM attacks on other visitors of the site. To do MitM attacks, you would need to have the private key matching the public key in the certificate to sign DH key exchange messages (or decrypt encrypted secrets in obsolete configurations of TLS).
Sometimes it is important to be precise when saying "I have the certificate" or "I have the certificate and private key". But often it is obvious from context what is needed.
One thing may be added to Z.T.'s answer: the confusion is likely to be caused by the implementation of cryptography in Microsoft Windows (maybe other systems as well).
In the administrative UI, both certificates and their correspondent private keys are managed via "Certificates" snap-in of management console.
In .NET framework the class
X509Certificate2, used to represent a digital certificate, has properties
PrivateKey. The documentation for the latter says "Gets or sets the AsymmetricAlgorithm object that represents the private key associated with a certificate". However, since the common convention is that a field represents something belonging to the object, the developer is likely to assume that private key is a part of the certificate, not just something related to it.
Finally, private keys as files are rarely handled on their own, but are typically packaged together with public keys and certificates into .pfx files. These files might be called "cryptographic containers", or something like that, but when you open them, the application title is "Certificate Import Wizard", so people just call them "certificates".
All this gives the developer a mental picture of certificate as an entity containing both public and (sometimes) private keys. Apparently, this is technically wrong: certificates are only associated with keys but don't contain them. However, I have to admit that I have developed .NET applications using digital encryption and signing for a couple years, and today is the first time I learned that my understanding of the term "Certificate" was incorrect. Nor have I ever been corrected when I talked about using certificates to sign/decrypt something in meetings with other developers.