SSL errors using MailChimp's API - ssl

I'm trying to connect with MailChimp's API, but keep getting errors:
Error. API call to lists/list failed: SSL peer certificate or SSH
remote key was not OK
Then, I created a cacert.pem file and set it in the Mailchimp.php file:
$this->ssl_cainfo = ROOT . DS . 'cacert.pem';
And get this:
Error. API call to lists/list failed: SSL certificate problem, verify
that the CA cert is OK. Details: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
or
Error. API call to lists/list failed: SSL peer certificate or SSH
remote key was not OK
Per this page:
I tried using the http://curl.haxx.se/docs/caextract.html file for my cacert.pem file, but that gives the "not OK" error listed above.
I also tried making my own with the info provided by our host (a text file, changed extension to .pem, and pasted one and/or both chunks of data into it, making it look like this):
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
or just one:
-----BEGIN CERTIFICATE-----
adjkflsdjflkasjdflkajdflksdflsdfkj
asldfkjaadsfhjkfhdsajkfhakjdhfkjdh
....
-----END CERTIFICATE-----
At a loss for where to go from here, what to try...etc
Using the example code from here: https://github.com/mailchimp/mcapi2-php-examples
And getting the Vendor files via composer:
"require": {
"mailchimp/mailchimp": ">=2.0.0"
},

Having spoken to MailChimp, the certificate they're still (Jan 2016) using – for compatibility reasons, they told me – is the GTE CyberTrust Global Root (note GTE was bought by Digicert), so you don't need to replace the entire bundle, just add or force PHP to read this certificate:
https://gte-cybertrust-global-root.digicert.com/info/index.html
(note you'll get an 'insecure connection' warning if you try and load that in Firefox, for hopefully obvious reasons – you can add an exception.)
It's in standard .crt format, which is what you need. Guide to certificate formats
You didn't specify what the server was but here's how to add an extra one on Linux without having to replace an entire bundle etc:
On Debian/Ubuntu, certificates live in /etc/ssl/certs/
Copy and paste the signature into a new file in that directory, e.g. mailchimp-legacy.crt
run sudo c_rehash /etc/ssl/certs - What's going on here: c_rehash calculates a short hash of each certificate and creates a symlink from that to the original .pem or .crt file. Basically it's a quick lookup table for openssl - openssl will perform the hash as well and look for the symlink, rather than having to have a database of certificate names or open every file in turn to find the right one.
check it's worked with this: ls -lh *.0 | grep 'mailchimp-legacy.crt'
You should see something like this:
lrwxrwxrwx 1 root root 20 Feb 13 14:17 4d654d1d.0 -> mailchimp-legacy.crt
lrwxrwxrwx 1 root root 20 Feb 13 14:17 c692a373.0 -> mailchimp-legacy.crt
Alternatively: On Debian, there's also a file called /etc/ca-certificates.conf and the exclamation mark in the line !mozilla/GTE_CyberTrust_Global_Root.crt indicates not to use that one. I believe it's possible to put a copy of the certificate with that name under /usr/share/ca-certificates/mozilla and run sudo update-ca-certificates, but it seems to me it be likely to be removed again when the package & config file are next updated.
Remember to remove any workarounds you were using - e.g.
- old CA bundles in your certificate directory
- anywhere you override CURLOPT_CAINFO in your PHP
- an openssl.cainfo line in your php.ini
Check your application works correctly. I didn't need to restart PHP or my webserver, the change was instant. Worth using apt-get update/upgrade to check you have the most recently certificate packages.
Here's a way to verify SSL connection (and verification) to a specific server from the command line:
echo GET | openssl s_client -CApath /etc/ssl/certs/ -connect us3.api.mailchimp.com:443 2>&1
Monitoring: (updated) MailChimp's v2.0 API (deprecated) has an endpoint called 'helper/ping' which returns some text to indicate the API status - useful as an automated test of API health and that your certificates are all still working. If you're using v3.0, they recommend using the API Root Resource and appending ?fields=account_name if you don't actually need to check any of the data.
Someone asked in the comments if this was related to Heartbleed. No. Heartbleed is an openssl vulnerability related to eavesdropping on data in RAM. Mozilla removed GTE CyberTrust (twice) because they wanted to remove all 1024-bit root certificates - research has suggested a nation state could break a 1024-bit prime.

You need the older certificates:
https://github.com/bagder/ca-bundle/blob/e9175fec5d0c4d42de24ed6d84a06d504d5e5a09/ca-bundle.crt
As defined on the page:
http://curl.haxx.se/docs/caextract.html
RSA-1024 removed
Guess Mandrill an Mailchimp use a RSA-1024 version.
That is the one you need. I had the same issue.

Debian and other operating systems and browsers have removed 1024-bit certificates because they are no longer considered secure. But Mailchimp has not switched to a higher-security certificate yet. Therefore you will have to manually re-add the old certificate to you system.
On debian, the correct solution is to follow the instructions in Alternative chain verification failure after 1024b root CAs removal:
First, Go to GTE CyberTrust Global Root and copy the Certificate: section (include -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. Paste it into the file
/usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt with this command: cat > /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt.
Check that it's good with the command: openssl x509 -in /usr/share/ca-certificates/mozilla/GTE_CyberTrust_Global_Root.crt -text -noout
To enable that certificate, add this line to /etc/ca-certificates.conf: mozilla/GTE_CyberTrust_Global_Root.crt
Update debian's certificates: update-ca-certificates

In your AppController, when you are creating a new Mailchimp instance, you can actually pass the following options:
'ssl_verifypeer'
'ssl_verifyhost'
'ssl_cainfo'
These get mapped to Curl when Mailchimp is requesting data.
So to start with, I'd try modifying line 44 of AppController to look something like this:
$this->mc = new Mailchimp('yourAPIKey', array('ssl_verifypeer' => false)); //your api key here
This will allow you to verify that it's the peer certificate that is causing issues. Of course I don't recommend that you consider this a valid solution for production, it's just a troubleshooting step.

Related

curl certificate Error_ssl.c334: No root certificate specified for verification of other side certificate

"""You also need CA certificates bundle file for SSL support. Download cacert.pem from the cURL site, rename it to curl-ca-bundle.crt, and place in the directory where you make installer, or in any directory listed in PATH environment variable."""
I did the same and stored it in "c:\python27"
but it gives me the following error.
value "C:\Python27\caret.pem" is not valid for "ssl.ca_certs"
No valid trusted SSL CA file set . See 'bzr help ssl.ca_certs" for more information on setting trusted certificates.
I got past this error by skipping the rename step.
I downloaded cacert.pem to "C:\Python27\" (no name change) and these errors went away.

OpenShift with Comodo SSL

I am trying to upload the SSL certificates for my OpenShift gear's alias. I used the instructions here: http://cloudhostingsource.com/setup-ssl-certificate-openshift/
I am stuck however at the uploading part - I have already genereated the CSR, activated the certificate. Every time I try to upload the files it takes me back to the same page without so much as a notification.
Comodo SSL sent me 4 files:
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
myApp.crt
How do I upload these? There are three fields to upload for Openshift... Which do I load into SSL Certificate? Certificate chain? I have my private key and I know the keypass.
Thanks
Just wanted to post an update for this for users who run into this issue in the future... I'm not sure if it was because I had added a public SSH key via the RHC setup but nothing I did (no permutations of copy paste chaining, switching files around) would work via the file uploader.
In the end, before deciding to call Red Hat and QQ, I used the command line console to add the SSL files...
Here is the command I used:
rhc alias update-cert php www.myapp.com --certificate myApp.crt --private-key myApp.key --passphrase mypass
This link includes more info: https://access.redhat.com/documentation/en-US/OpenShift_Online/2.0/html/User_Guide/Using_Custom_SSL_Certificates1.html
TLDR: You don't need to combine any of the Comodo files, just use your file #4, your privatekey, and your passphrase (if you have one)
Thats right!
First combine public with bundle:
cat dom_com.crt dom_com.ca-bundle >> dom_com.ALL.bundle
and upload both:
rhc alias update-cert app dom_com \
--certificate dom_com.ALL.bundle \
--private-key dom_com.key
And then you will obtain an A at https://www.ssllabs.com/ssltest/
You need to combine 1,2, and 3 into one chain certificate (in the correct order) and upload them in the chain certificate field, the key goes in the key field, and the myApp.crt goes in the certificate field.
I had a similar problem, and after some back and forth emails with the Certificate issuer, what helped me was to combine my site certificate with the Certificate chain into one file, and uploading it into the "SSL Certificate" field in OpenShift. I left the "SSL Certificate Chain" field blank, but of course I uploaded my public key in the "Certificate Private Key" field.

Boost Asio SSL Client Handshake Problems

I have been trying to implement a very basic Boost SSL implementation to try and learn the basics. The server I want to communicate with had already given me their public key in plain text. I already put a lot of the other code (asynchronous connection, handshaking, etc) in.
I first tried to implement SSL without verification of their certificate using the following setup of the Boost SSL stream:
boost::asio::ssl::context ctxt(boost::asio::ssl::context::sslv23);
ctxt.set_verify_mode(boost::asio::ssl::verify_none);
This implementation worked fine and I was able to connect with the server. When I tried to implement the verification of the peer certificate, however, the handshaking fails. I tried using the following code:
boost::asio::ssl::context ctxt(boost::asio::ssl::context::sslv23);
ctxt.set_verify_mode(boost::asio::ssl::verify_peer);
ctxt.load_verify_file("peer.crt");
I put the "peer.crt" containing the public key (along with the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tags) in the directory where I am running my executable. For whatever reason the handshake now fails with the error code 336134278: certificate verify failed. I also tried putting the full path to the verify file in there but with no luck.
My questions are the following:
Where should I be specifying the file name for the verify file in load_verify_file? Is it simply in the directory where I am running my executable?
Am I not setting up the handshaking process with peer verification properly? I do not have my own verify callback as I assumed the peer verification would happen automatically if I specified it as such.
Should I be handling the certificate in a certain way by installing it or something like that?
Is there a better way of debugging this functionality? I am using VS10 and can only get to the ipp so I cannot actually view the verification taking place.
Any help is appreciated, thanks!
You should be able to use either a relative or absolute path.
Your use of set_verify_mode() and load_verify_file() looks fine. I have done exactly this in my own code. A default verify callback is used if you do not specify one.
You don't need to "install" the certificate.
I don't know of easy ways to debug boost::asio SSL connections, but you can use OpenSSL command line tools, such as s_client, to test connections. boost::asio uses OpenSSL under the hood.
I suspect that you don't have the entire certificate chain of certificates in your file. You can extract them from your server with (replace www.google.com:443 with your server and port):
openssl s_client -connect www.google.com:443 -showcerts
If you only wish to check some of the certificates, e.g. only the leaf certificate, you can use your own verify callback. An example of a custom callback, as well as a description of the verification modes and options are on this page.
A good place to start is the HTTP Client in asio examples.
Are you calling set_verify_callback on the socket with the callback function to verify the certificate? E.g.:
bool verify_certificate(bool preverified, boost::asio::ssl::verify_context& ctx)
{
char subject_name[256];
X509* cert = X509_STORE_CTX_get_current_cert(ctx.native_handle());
X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256);
return preverified;
}

SSL ASN1 Encoding routines and x509 certificate routine errors

I'm completely new to anything Secure Socket Layer related up until yesterday evening and today. I need to get a self-signed certificate to proceed with an app registration process so that I can implement OAuth in an app I'm writint. I went through a nice tutorial about how to generate certificates here. I'm an ubuntu user, if you didn't click the link to figure that out. I've been trying to generate a self-signed 1024 bit RSA key encoded x.509 certificate in PEM format. After setting up the configuration and doing everything as is on the tutorial (of course with the exception of specifying the environment-related data to my own environment). The commands to generate a new certificate and key after going through the configuration are:
forces SSL to look for configuration file in alternate location (the server configuration file):
export OPENSSL_CONF=~/myCA/exampleserver.cnf
Generate the certificate and key:
openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM
Following those two commands the following is displayed:
Generating a 1024 bit RSA private key
...++++++
...............++++++
writing new private key to 'tempkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
I enter my pass phrase and the error I continually get is:
problems making Certificate Request
3074111688:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:109:
3074111688:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:x509name.c:285:name=organizationUnitName
I ran into a similar problem while following the same tutorial that you mentioned. In my case, the error was:
problems making Certificate Request
140098671105696:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:a_mbstr.c:154:maxsize=2
So I figured out that I've written some string which should have been 2 characters long (maxsize=2), but happened way longer. I returned back to my config file and quickly found that I've wrote the long name of the country, instead of the 2-character code. This solved my problem.
not really familiar with the process but, it appears "invalid field name:x509name.c:285:name=organizationUnitName" means your Organization Unit Name is invalid.
According to digicert.com: The Organizational Unit is whichever branch of your company is ordering the certificate such as accounting, marketing, etc.
it depends on what is in your conf file, the openssl ca tool looks for sections in the file, those sections look for other sections, some of the section names are mandatory and some of the name/value pairs in sections are mandatory.. it's quite a big configuration space offered by this file
The error you mention comes up when openssl doesnt recognise a name inside a section in different scenarios, e.g. i've seen it when I was adding a custom oid for an end-entity cert, and also when customising contents of a ca cert.
if you post your configuration file and what you expect in the resulting ceritifcate then we can help. Also can you say what you intend to use the certificate for (e.g. secure a client session on a production webservice or something else)
I had the same problem, had C=USA instead of C=US
I had a similar issue. I followed the advice from GitHub using the countryName_default parameter. It seems like this parameter does not exist on my openssh.exe, contrary to the advice on GitHub.
Once I removed any xxx_default parameters from the [ req_distinguished_name ] section of the SSL xxx.conf file, the creation of the certificate succeeded.
This is working on Windows 10.

SSL Certificate add failed when binding to port

I created a WebService using WCF. I'm doing self hosting and I want to enable HTTPS. From my understanding for this to happen, I need to create a certificate and bind to the port that I want to use.
Here are the steps that I've done to handle this:
Created a Certificate on my local machine to act as the Root Certificate Authority
makecert -n "CN=My Root Certificate Authority" -r -sv RootCATest.pvk RootCATest.cer
Opened MMC.exe and imported the saved .cer file into the "Trusted Root Certificate\Certificates\ folder
makecert -sk MyKeyName -iv RootCATest.pvk -n "CN=MyMachineName" -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer
Created a temporary service certificate from the signed Root Certificate Authority
makecert -sk MyKeyName -iv RootCATest.pvk -n "CN=MyMachineName" -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer
Tried to Bind the Certificate to the Port number (443 in this case)
netsh http add sslcert ipport=0.0.0.0:443 certhash=2c5ba85bcbca412a74fece02878a44b285c63981 appid={646937c0-1042-4e81-a3b6-47d678d68ba9}
The result from step 4 is the following error:
SSL Certificate add failed, Error 1312
A specified logon session does not exist. It may already have been terminated.
Does anyone have a clue why I might be getting this error?
I had the same error. The first time it occurred, as Micheal said, I had to move the certificate under Certificates(Local Computer) -->Personal -->Certificate folder. I had the same error when I imported the same certificate on another machine. The reason was that I was using certmgr.msc to import the certificate. . The window opened thus shows “Certificates – Current User”. Certificates imported using this window cause netsh to fail with the 1312 error. Make sure to use certificate snap-in in MMC to import certificates. The certificate snap-in from MMC shows “Certificates (Local Computer)”. This lets the netsh execution sail through.
SSL Certificate add failed, Error 1312
A specified logon session does not exist. It may already have been terminated.
I used to have the exact same problem and spent a couple days trying to figure out what the reason was.
To make the long story short: the problem is that you have installed the certificate on the winrm server that does not have PRIVATE KEY.
I have checked this several times. You have to delete your certificate and rebuild it by using makecert for instance, as it is described perfectly here: http://blogs.technet.com/b/jhoward/archive/2005/02/02/365323.aspx
You can easily check if your certificate has private a key as so: mmc - certificates - local machine - personal. Look at the icon of the certificate - it MUST have key sign on the icon.
I have bought an official Thawte certificate to secure a self hosted (console application) web service over a specific port on our internet server.
I then have received the Thawte certificate and installed it with mmc on our Internet server (the certificate then was viewable under „Trusted Root Certification Authorities“ (with the key icon on the image, what shows that the certificate contains a private key what is mandatory to be able to bind it to a port b.t.w.) .
Next step was to enable the <port> for https:
netsh http add urlacl url=https://+:<port>/ user=everyone
(what was no problem)
Next step was to enable the port () for https:
netsh http add sslcert ipport=0.0.0.0:<port> certhash=<thumbprint to certificate> appid={<guid to application>}
This has failed with the error message:
SSL Certificate add failed, Error: 1312 A specified logon session does not exists. It may be already have been terminated.
I then have searched the Internet and tried various suggested workaround’s (without success).
The solution for my case was to add certstorename=Root to the netsh command:
netsh http add sslcert ipport=0.0.0.0:<port *1)> certstorename=Root certhash=<thumbprint to certificate *2)> appid={<guid to application *3)>}
Notes:
If no certstorename is applied to net netsh command, netsh takes the default, what is MY (what targets the certificate store: “Personal” where self signed certificates are stored normally).
Root targets the certificate store: „Trusted Root Certification Authorities“
*1): The port, you want to use the connection
*2): You can extract the thumbprint to the certificate, if you open the certificate (on a windows system, just doubleclick the certificate in explorer) - select tab “Details” and click on “Thumbprint”. The “thumbprint” then is showed and can be copied. Copy the Thumbprint and remove all spaces...
*3): As appid you can take any ID in the form {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} as the APPID is only informative.
With the command “netsh http show sslcert” you can query the bound certificates on the whole machine and the will see informative, which appid is bound to which certificate (not really helpful in practice b.t.w.)
In my case, I have took the (from VS generated) GUID to my web service application
I had been dealing with this issue and I'm using a self-hosted WCF service. I just made the breakthrough:
I had a certificate in the personnel folder for the Machine store. It expired and my manager issued a new one. The new one failed for me with this error. I tried a lot of stuff from Google but in the end, resolved the issue using a completely different solution.
I installed both certificates- the expired one and the newer one. Then I used this command to get a list of them:
certutil -store My
I get this output (info is fake and other certificate are not listed):
================ Certificate 1 ================
Serial Number: 6d
Issuer: E=operations#voicetrust.com, CN=VoiceTrust Server CA, OU=VoiceTrust Oper
ations, O=VoiceTrust
NotBefore: 03-Jan-2013 3:33 PM
NotAfter: 03-Mar-2013 3:33 PM
Subject: E=hgulzar#voicetrust.com, CN=hornet.voicetrust.com, OU=Software Develop
ment, O=VoiceTrust eServices MENA FZ LLC, L=Dubai, C=AE
Non-root Certificate
Cert Hash(sha1): 98 5f a0 d3 11 6a 4b 64 3b db 0a a4 11 66 fc 08 28 74 7e 53
Key Container = {E5BC0912-7808-4B89-B457-31946DE5990E}
Unique container name: dfedfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b6
4-30f0d6589239
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Encryption test passed
================ Certificate 2 ================
Serial Number: 6d
Issuer: E=operations#voicetrust.com, CN=VoiceTrust Server CA, OU=VoiceTrust Oper
ations, O=VoiceTrust
NotBefore: 03-Nov-2013 3:33 PM
NotAfter: 03-Dec-2013 3:33 PM
Subject: E=hgulzar#voicetrust.com, CN=hornet.voicetrust.com, OU=Software Develop
ment, O=VoiceTrust eServices MENA FZ LLC, L=Dubai, C=AE
Non-root Certificate
Cert Hash(sha1): 30 5f a0 d3 11 6a 4b 64 3b db 0a a4 11 66 fc 08 28 74 7e 53
Key Container = {E5BC0912-7808-4B89-B457-31946DE5960E}
*Unique container name:* 55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b6
4-30f0d6589239
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Encryption test passed
Now, everything seems OK but certificate 1 is expired and works if I try to bind it to a port whereas Certificate 2 fails with Error 1312.
The key difference that baffled me was the Unique container name property. It should be representing a physical key file on the hard drive in the %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\
For Certificate 1, the file was there but for Certificate 2, there was no such file. After searching I found the file against Certificate 2 in the sub folder of %AppData%\Microsoft\Crypto\ folder. That's user specific keys not Machine level keys. It's amazing that the certificate is being imported into Computer store yet it always keeps the container key of User's store.
I deleted the '55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b64-30f0d6589239' file under the AppData folder and ran the repair command for my certificate 2 on the store:
certutil -repairstore My 2
This time, the Unique container name was reflecting a file in the proper folder under '%ProgramData%\Microsoft\Crypto\' and everything started working.
Hope this is helpful to someone.
I've been fighting error 1312 all day, what fixed it for me was to import the certificate in mmc as a .p12 file instead of a .crt. If you are creating it with OpenSSL then once you have created the .crt, do:
pkcs12 -export -in server.crt -inkey server.key -name “Your Name” -out server.p12
As described. When you go to import it in mmc it will be a called "Personal Information Exchange" file (and apparently a .pfx file would also work).
I'm new to writing servers and dealing with SSL and I have no idea why this works, but I hope it helps.
The problem was in step 4. I was using the Thumbprint from the Root Certificate for the value in certhash. To solve this I had to go back to the MMC and refresh the Certificates(Local Computer) -->Personal -->Certificate folder. Then use the Thumbprint from the certificate that is "Issued By" the Root Certificate Authority.
I my case the problem was that the CER file hasn't private key attached.
I've attached PK using those OpenSSL commands:
openssl x509 -in server.der -inform DER -out server.pem -outform PEM
openssl pkcs12 -export -in server.pem -inkey serverkey.pem -out server.p12
Works for CER/DER files.
I had the same problem and solved importing the certificate using this command:
c:> certutil -importPFX certname.pfx
Now the certificate appear using this command:
c:> certutil -store my
before this command the certificate doesn't appear
This might seem obvious; however, I think it can save someone some time of head scratching. I had imported a file with .cer extension under my Personal certificates folder (for the Personal Computer account). After a while, I realized that I needed to import the file with the *.pfx extension instead. Fixed that and voilà! Problem solved!
There are multiple ways of receiving this error (see above for other answers).
Another way to receive this specific error is to attempt to bind a certificate to a port when the certificate is not in the appropriate store.
Verify that the certificate is stored in the localMachine Root store (you can use certutil or certmgr.exe from command line to dump it correctly).
updated grammar :)
If anyone else runs into this problem and the answers in here do not clearly answer it, the underlying core problem is the private key needs to be imported. If you do not mark the certificate as exportable when you import it, the private key is not imported and you cannot bind it. If you delete it and re-import it and mark it as exportable, then it will work.
It also needs to be the local machine store as others have pointed out.
If:
you didn't have IIS on your machine (working with self-hosted WCF let's say), and
you made your cert request on another machine using IIS Manager (because you didn't understand that the private key comes from ciphers embedded in the cert request - and later the issued .pb7)
then:
just go install the .pb7 on the IIS machine you used to make the cert request (local machine/personal/certificates - using mmc);
export the cert from that machine, including its private key (assign password); and
install it using mmc on the WCF server (local machine/personal/certificates - using mmc).
Then, netsh will let you bind to port 443. No more 1312 errors.
Just to throw yet another answer into the ring, this is the problem I had:
Although I imported my certificate into the (Local Computer)\... certificate store, I had imported it into the Trusted Root Certification Authorities section. I needed to import it into the Personal section, otherwise this error occurred.
In my case, i have missing the certificate private key.
IF you imported the certificate using .NET, specific import flags must be used:
/// <summary>
/// Imports X.509 certificate from file to certificate store.
/// </summary>
/// <param name="fileName">Certificate file.</param>
/// <param name="password">Password.</param>
/// <param name="storeName">Store name.</param>
/// <param name="storeLocation">Store location.</param>
public static void ImportCertificate(string fileName, string password, StoreName storeName, StoreLocation storeLocation) {
var keyStorageFlags =
X509KeyStorageFlags.PersistKeySet
| (storeLocation == StoreLocation.LocalMachine ? X509KeyStorageFlags.MachineKeySet : X509KeyStorageFlags.UserKeySet);
var cert = new X509Certificate2(fileName, password, keyStorageFlags);
var store = new X509Store(storeName, storeLocation);
store.Open(OpenFlags.MaxAllowed);
store.Add(cert);
store.Close();
}
The ImportCertificate method is a part of the Woof.Security package created by me.
https://github.com/HTD/Woof.Security
https://www.nuget.org/packages/Woof.Security/
This is my summary of all the fixes in this thread and how it worked for me:
Find "Windows PowerShell", right-click on the icon, and choose "run as administrator".
Find "Wordpad", right-click on the icon, and choose "run as administrator". (this is so you can copy and paste between PowerShell and Wordpad.)
In PowerShell run "netsh HTTP show sslcert".
From the info that shows, copy the "Certificate Hash", "Application Id", and "Certificate Store Name". (You'll need all these in a moment.)
(If you need to) locate your *.cer or *.crt file and export it as a *.pfx file.
In Powershell, navigate to the folder of your *.pfx file.
Now run "certutil -importPFX .pfx".
Then run "certutil -store my" to show the installed certs.
Now using the info from step #4 run this "netsh http add sslcert ipport=0.0.0.0:8000 certstorename= certhash= appid='' (I had to put them in this order, with my cert store name, and single quotes around the app id.)
Check that the SSL cert was added by running "netsh HTTP show sslcert" again.
I had exact same problem eventhough my .pfx file had private key. Adding of certificate with MMC console was successful, but adding programatically using .Net X509Store.Add(X509Certificate2) method failed every time with error 1312. Certificate even had a key sign on the icon.
After several days finaly decided to make new certificate using makecert.exe as suggested in posts here. After that everything was fine. Key appeared in %ProgramData%\Microsoft\Crypto\RSA\MachineKeys. For some reason my earlier pfx file was not compatible.
In my experience, as long as your key in not appearing in %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\, binding with 'netsh http add sslcert ....' will fail.
The certstorename argument should be the string value of the StoreName enumeration from the .net framework namespace System.Security.Cryptography.X509Certificates.
I've being working on this for hours, and basically read through what #DoomerDGR8 said above, but my fix was a lot more simple. I ran
C:\Windows\system32> certutil -store TRUSTEDPUBLISHER
This listed several certificates I have installed, I then ran repair store on the certificate that I was having a problem installing with netsh.
C:\Windows\system32> certutil -repairstore TRUSTEDPUBLISHER 6
The number 6 at the end represents the index of your certificate, found at in the store, hope this helps
In my case while creating the certificate I chose a different name than My for my Cert Store name. The default name is MY. So if yours is different append certstorename=Your provided store name to the command.
I had the same error when creating self signed certificate with OpenSSL(BouncyCastle) I resolved it with help from this post:
Cannot export generated certificate with private key to byte array in .net 4.0/4.5
I had to add:
RsaPrivateKeyStructure rsa = RsaPrivateKeyStructure.GetInstance(seq); //new RsaPrivateKeyStructure(seq);
RsaPrivateCrtKeyParameters rsaparams = new RsaPrivateCrtKeyParameters(
rsa.Modulus, rsa.PublicExponent, rsa.PrivateExponent, rsa.Prime1, rsa.Prime2, rsa.Exponent1, rsa.Exponent2, rsa.Coefficient);
var rsaPriv = DotNetUtilities.ToRSA(rsaparams);
var cspParams = new CspParameters
{
KeyContainerName = Guid.NewGuid().ToString(),
KeyNumber = (int)KeyNumber.Exchange,
Flags = CspProviderFlags.UseMachineKeyStore
};
var rsaPrivate = new RSACryptoServiceProvider(cspParams);**
// Import private key from BouncyCastle's rsa
rsaPrivate.ImportParameters(rsaPriv.ExportParameters(true));
// Set private key on our X509Certificate2
x509.PrivateKey = rsaPrivate;
So to add (yet) fix/situation.
I had C# code that used BouncyCastle to create self-signed certificates.
<packages>
<package id="BouncyCastle" version="1.8.1" targetFramework="net45" />
So my code created the certificates AND placed them in the correct locations in the Cert-Store.
Using the hints here, my install of On Premise Service Bus 1.1 was failing...and that led me here.
I ended up DELETING both certificates my BouncyCastle code had created (from the cert store) and reimporting them (with private keys)....and it all worked.
I imported FIRST to the
Certificates (Local Computer) / Personal / Certificates
then I copied pasted (in the mmc) to any other places (stores) I needed them.
My "before" and "after" looked exactly the same from my eyes in MMC, BUT it fixed the issue. Go figure.
I just had yet another error. I renewed an expired cert for our WorkFolders service from our CA using the same private key. Then I always got Error 1312. Even if Certificate Management shows I have a private key.
I could only solve the problem by re-issuing a new certificate (without the renew option). Then it worked on the first try.
Maybe this will help someone who also tried the renew option.
For me the problem was solved by ensuring that the certificate hash I was using in my command line, corresponded to the certificate installed on my server:
netsh http add sslcert ipport=0.0.0.0:8081 certhash=1061a577f0cc1c428186000dc84f02a7111ca1b2 appid={GUID}
On my side, the files provided were a P7B file together with a bunch of cert files. After getting stuck, I asked for my colleague's help and he gave me an idea to import the certificates together with the private key via a PFX.
This article gave me the instruction to convert the P7B file into PFX. To summarize, you simply have to do the following:
Use openssl to convert the P7B file into PEM first
Convert the PEM file into PFX
You can now import the PFX file. Better to read the article I stated above because it has significant information to note.
Finally I solved it. The problem is the certificate file. I tested it other mac and failed it. Here is my solution.
Remove .cer file
Re-create certificate file.
If failed, also re-create CSR file.
Thank you.
Looks like this is a generic error. My fix is unlike all the rest.
Using Azure Devops for a deployment, the step IIS Web App Manage has the cert hash buried/hidden in IIS Bindings (which the only way to see the cert hash is to edit that specific piece), so you have to update the hash so it matches on the server you're deploying to. And voila, you're set.
I was getting this error when trying to deploy from an Azure Devops pipeline to a Windows Server box running IIS. The pipeline should deploy the site to IIS and then create an https binding where the existing certificate in the computer cert store was referenced by it's thumbprint. In the pipeline the thumbprint was meant to be drawn from variable group - however the correct variable group wasn't linked to the pipeline (and the variable name was wrong) - so it got nothing.
Basically the wrong thumbprint was being used to identify the cert, I suspect it wasn't giving a standard "can't find the SSL cert" message because I was attempting to find the cert with a null.