can Digital certificate signature be copied? (ssl)

Question

According to X.509 standard private key signature has to generate same encrypted message for ever?Am I right?

In order to avoid coping which data field in digital certificate will be changed?

they can't process the information of the user, but by coping the digital signature generated by private key and keeping along with the webpage attacker can say that I am certified by the CA and web browser will agree with that information.Is it true?

Version number,Serial number,Certificate algorithm identifier,Issuer name,Validity period,Subject name,Subject public key information Issuer unique identifier,Subject unique identifier,Extensions,Certification authority's digital signature. These are the fields in digital certificate,if this fields don't change for ever,encrypted value will be same for ever.If I go to gmail it sends Encrypted digital certificate.If I use that Encrypted digital certificate in my webpage cant I say I am owner of gmail.but I can't use information send by the user since I won't have private key

Answer 1

A certificate must be signed by a CA in order to be considered as valid. The contents of the certificate is hashed, then encrypted by the CA's private key. Anyone can then validate whether the certificate is valid by decrypting the signature with the CA's public key, and verifying whether the hash matches.

The signature verifies that a particular name is associated with a particular public key - even if someone copied the certificate file verbatim, they wouldn't know the private key corresponding to that public key, and so they couldn't use it to impersonate the owner of the certificate.

Answer 2

I was wondering the same question.

Reading @Anon.'s answer led me to this: https://en.wikipedia.org/wiki/Transport_Layer_Security#Description

The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).

From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.

The server usually then sends back its identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) that vouches for the authenticity of the certificate, and the server's public encryption key.

The client confirms the validity of the certificate before proceeding.

To generate the session keys used for the secure connection, the client either:

• encrypts a random number with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session or

• uses Diffie-Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party.

It looks like in your forgery example (that I was wondered also) the client confirms the certificate successfully in paragraph 4. And then in paragraph 5 they fail to agree on session key as the server cannot read client's random number.