I see that some product are shipped with a default server certificate. I guess that a lot of these installed products still use the default server certificate in a real environment.
If your server certificate is known (eg. someone know which server certificate you are using and can download it), is your HTTPS still secured even if nobody can access your server(s) ?
In another point of view, is HTTPS or SSL with a 'public' server certificate can be called 'security' ?
To get terminology straight: the certificate is the public part. It is public so everybody knows it, and when a client connect to a SSL server, that certificate is one of the first things that the server sends to the client. What you mean is: when the private key is not really private, can SSL still be considered as "secure" ?
The answer is basically: No.
However, there are subtle details. When client and server talk to each other, they agree on a set of cryptographic algorithms to use, called the cipher suite. See the standard for (most of) the currently defined cipher suites. One of the elements of the cipher suite is the key agreement method used to exchange the "pre-master secret" from which all other keys are derived. When the cipher suite is a basic "RSA" suite (i.e. the cipher suite names begins with "TLS_RSA"), then the key agreement is basic asymmetric encryption with RSA: the client generates a random pre-master secret, encrypts it with the server's public key (from its certificate), and the server decrypts it to recover the pre-master secret.
When the server's private key is known to an attacker who merely eavesdrop on the channel, then that attacker can also decrypt the message from the client, obtain the pre-master secret, and decrypt all the data. It seems safe to say that, under these conditions, there is very little security left.
However, if the negotiated cipher suite is of type "ephemeral Diffie-Hellman" (the name begins with "TLS_DHE"), then the actual key agreement uses Diffie-Hellman with public/private DH key pairs which have been randomly generated on the spot. The server's private key (the one which is hardcoded and thus not very private at all) is used only to sign the DH public key. Under these conditions, a purely passive attacker, who merely spies on the data packets but does not interfere, will not be able to get the pre-master secret, and the connection will remain secure. This feature of DHE is called Perfect Forward Secrecy.
However, even with DHE, an active attacker can impersonate the server and mount a Man-in-the-Middle attack, voiding any security. PFS is an actual advantage only when considering the case of a private key ulterior theft, where the attacker steals the server's private key after the connection has occurred. At that time, it is too late for the attacker to be "active", and PFS locks him out. But this is not your situation: you envision a case where the attacker already knows the server's private key when the connection happens. The attacker can then mount an active attack.
So, to sum up: when the server's private key is known to attackers, then security is maintained only against passive-only attackers, and then only if the client and server agree on a DHE cipher suite.
(Strictly speaking, security can be salvaged even against active attackers if the cipher suite is DHE and the server requires a client certificate and the client private key is not known to the attacker. That's an edge case.)
If you use an SSL certificate where someone knows the private key, it could be possible for them to decrypt the data in transit between the client and server, assuming they can get access to the data (for example by sniffing the traffic going over a wireless network)
Also unless you use perfect forward secrecy if an attacker can get access to a stored copy of your transmissions at a later date and they have the server private key they will also be able to decrypt the transmission.
so yes if someone uses a server certificate (e.g. in an appliance) where it's shipped with the system there is a risk if they don't change the certificate. You'd hope that vendors would either advise a change of certificates in their documentation or, better, force it when the device is commissioned.
