Risks associated with distributing encrypted private key with our software?

Question

Our software contains two executables that need to serve data over SSL (and several that need to do requests over HTTPS)).
I notice that it is distributed with some .PEM files created with OpenSSL. These files are read by the software when it needs to consume or serve over HTTPS.
The second file says: BEGIN ENCRYPTED PRIVATE KEY

Question: If private keys should never be distributed, is it OK to distribute the encrypted version?
Do we run any risks with that?

I have read Is it bad practice to add an encrypted private key to source control?, but I'm still unclear about the possibility for others to do something malicious (spoofing?) with that encrypted private key.

(BTW There is actually a third intermediate certificate because of the issue of RapidSSL certificates not being trusted on Android, but that seems irrelevant to the question).

First file

Header:

Bag Attributes
    localKeyID: 01 00 00 00 
    friendlyName: TimeTellbv wildcard
subject=/serialNumber=34VD79pOnKBR2dM5LC69jkD7PGuRM6VC/OU=GT04962750/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.timetellbv.nl
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
-----BEGIN CERTIFICATE-----

Converted to text with

c:\OpenSSL-Win32\bin\openssl x509 -in tt_https.pem -inform PEM -noout -text >tt_https.txt

it reads:

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 962889 (0xeb149)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=GeoTrust, Inc., CN=RapidSSL CA
    Validity
        Not Before: Oct 23 04:44:55 2013 GMT
        Not After : Oct 25 11:45:46 2016 GMT
    Subject: serialNumber=34VD79pOnKBR2dM5LC69jkD7PGuRM6VC, OU=GT04962750, OU=See www.rapidssl.com/resources/cps (c)13, OU=Domain Control Validated - RapidSSL(R), CN=*.timetellbv.nl
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:d4:a4:bf:b9:bb:cf:f9:e9:88:95:f3:e5:c7:b9:
                [snip]
                e7:27
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Authority Key Identifier: 
            keyid:6B:69:3D:6A:18:42:4A:DD:8F:02:65:39:FD:35:24:86:78:91:16:30

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Alternative Name: 
            DNS:*.timetellbv.nl, DNS:timetellbv.nl
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://rapidssl-crl.geotrust.com/crls/rapidssl.crl

        X509v3 Subject Key Identifier: 
            CA:86:AC:B6:13:D3:96:F8:60:5F:DF:B2:F6:FA:28:E0:75:30:DB:D0
        X509v3 Basic Constraints: critical
            CA:FALSE
        Authority Information Access: 
            OCSP - URI:http://rapidssl-ocsp.geotrust.com
            CA Issuers - URI:http://rapidssl-aia.geotrust.com/rapidssl.crt

        X509v3 Certificate Policies: 
            Policy: 2.16.840.1.113733.1.7.54
              CPS: http://www.geotrust.com/resources/cps

Signature Algorithm: sha1WithRSAEncryption
     56:b9:59:c1:ed:d1:a5:84:2a:ce:96:14:0e:ad:db:fc:80:80:
     [snip]
     c7:7c:10:fb

Second file

Header:

Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: 01 00 00 00 
    friendlyName: le-0f8807ed-4cbe-43a6-84a9-94ef82e3fd39
    Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
    X509v3 Key Usage: 10 
-----BEGIN ENCRYPTED PRIVATE KEY-----

Conversion to text form fails:

c:\OpenSSL-Win32\bin\openssl x509 -in tt_https_key.pem -inform PEM -noout -text >tt_https_key.txt

unable to load certificate
2180:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib
.c:696:Expecting: TRUSTED CERTIFICATE

Answer 1

There are cases where you can actually distribute the private key (even unencrypted) but they are really borderline (for instance, you might want to lower the amount of ssl connections your server will accept before even performing client authentication but might not have the possibility of properly issuing each client his own client auth cert).

It doesn't looks like that's what you're doing here, though: that certificate is a wildcard server certificate certificate for the timetellbv.nl domain. It makes little sense to use that for client authentication (you would be better of using your own CA for that) so you're probably using it to serve file.

So, the next question would be: what type of deployment are we talking about ? If you're talking about a single-site deployment (i.e. that is your own certificate and you're deploying your own app on your own server), then it might be bad practice to place the certificates in the deployment package (see the question you linked), but it's not making your whole security invalid.

If, however, you're deploying an application from or to a third party, then this is a big no-no: the only way to make use of such certificate is to use it incorrectly: it is improper for identifying ANY system but the ones under the *.timetellbv.nl domain and shouldn't be used.

(As a side note, https://www.timetellbv.nl returns an invalid certificate: the DNS name does not match)