Dealing with SSL Certificates on Products
We are installing the same self-signed certificate into every development and prototype unit.
Installing the same certificate into every unit is about the worst security practice one could imagine when dealing with certificates. We now know not to release products with the default hard coded administrative credentials. We avoid default credentials because such credentials could be extracted once and used to compromise all devices that implement them. This is a very similar situation – the default certificate means the private key could be extracted once and used to compromise all devices that rely on this certificate.
Cryptographically, both self-signed and trusted third party certificates operate the same way. Each certificate is associated with a key pair consisting of a secret private key and a non-secret public key. If you know the private key, then you can perform every action associated with the public key and certificate.
The compromise of the default certificates has further implications than just compromising authentication. For TLS, depending on the cipher used, the certificate could end up being used to establish a shared secret. In such cases, a passive eavesdropper would be able to decrypt TLS traffic after seeing the initial handshake.
Sure, competent administrators will fix this issue by uploading their own unique certificates, but how many would actually stop at 'just make it work' stage by trusting the default certificate? What you should do instead is generate a new key pair on initial boot or factory reset. This is how secure network devices operate. When generating new certificate, you also have to make sure that you have sufficient entropy available in the system and do not end up generating factorable keys.
Customers will be able to provide their own certificates, signed in whatever manner they wish (publicly, or privately). This will give them the chain of trust, and will allow them to be sure that they really are connecting to that system.
This suggests that either A) a typical installation will have a "real" domain name, visible on the public internet (as opposed to an intranet domain name or private IP address) or B) a typical customer will have the necessary technical knowledge to operate their own internal certificate authority.
If (A) is true, then your product could dial out to Let's Encrypt and obtain a signed certificate that way. This requires that the service both has a "real" domain name, and that it is fully visible to the public internet (i.e. it is not firewalled on ports 80 and/or 443). Let's Encrypt certificates can be acquired in a fully automated fashion and do not require any manual steps, provided you both know and control (can serve web traffic from) the FQDN. Naturally, you should interact with the service in a reasonably "polite" manner, especially considering that it is free of charge (i.e. do not send it a large number of requests at once, implement exponential retry backoff, etc.).
If (B) is true, then you should definitely go with the option you describe (i.e. let the customer provide a certificate), because your customers are better positioned to solve this problem than you are. However, in most industries, (B) is not true. Nevertheless, a sufficiently adventurous customer might want the option of doing this, so you should provide it anyway.
If neither (A) nor (B) is true, then you should follow one of the other answers. In this case, a typical customer does not have the ability to provide a good certificate, so you should not make them responsible for doing so. You may still want to provide an option for using a custom certificate, but you should not make it the default.
You could do something like offer up a unique certificate for
product-serial-number.product-name.company-name.com
and have it issued by something that has something trusted in the certification path. The certificate would still not be trusted for that purpose, but someone could check the certificate against a sticker on the box (and optionally install it into their certificate store). Unfortunately, Chrome and Edge no longer make it easy to view certificate details on HTTPS pages, so this will be difficult.