root#sclrdev:/home/sclr/certs/FreshCerts# curl --ftp-ssl --verbose ftp://{abc}/ -u trup:trup --cacert /etc/ssl/certs/ca-certificates.crt
* About to connect() to {abc} port 21 (#0)
* Trying {abc}...
* Connected to {abc} ({abc}) port 21 (#0)
< 220-Cerberus FTP Server - Home Edition
< 220-This is the UNLICENSED Home Edition and may be used for home, personal use only
< 220-Welcome to Cerberus FTP Server
< 220 Created by Cerberus, LLC
> AUTH SSL
< 234 Authentication method accepted
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Relating to 'SSL certificate problem: unable to get local issuer certificate' error. It is important to note that this applies to the system sending the CURL request, and NOT the server receiving the request.
Download the latest cacert.pem from https://curl.se/ca/cacert.pem
Add the '--cacert /path/to/cacert.pem' option to the curl command to tell curl where the local Certificate Authority file is.
(or) Create or add to a '.curlrc' file the line:
cacert = /path/to/cacert.pem
See 'man curl', the section about the '-K, --config <file>' section for information about where curl looks for this file.
(or if using php) Add the following line to php.ini: (if this is shared hosting and you don't have access to php.ini then you could add this to .user.ini in public_html).
curl.cainfo="/path/to/downloaded/cacert.pem"
Make sure you enclose the path within double quotation marks!!!
(perhaps also for php) By default, the FastCGI process will parse new files every 300 seconds (if required you can change the frequency by adding a couple of files as suggested here https://ss88.uk/blog/fast-cgi-and-user-ini-files-the-new-htaccess/).
It is failing as cURL is unable to verify the certificate provided by the server.
There are two options to get this to work:
Use cURL with -k option which allows curl to make insecure connections, that is cURL does not verify the certificate.
Add the root CA (the CA signing the server certificate) to /etc/ssl/certs/ca-certificates.crt
You should use option 2 as it's the option that ensures that you are connecting to secure FTP server.
I have solved this problem by adding one line code in cURL script:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
Warning: This makes the request absolute insecure (see answer by #YSU)!
For me, simple install of certificates helped:
sudo apt-get install ca-certificates
In my case it turned out to be a problem with the installation of my certificate on the service I was trying to consume with cURL. I failed to bundle/concatenate the intermediate and root certificates into my domain certificate. It wasn't obvious at first that this was the problem because Chrome worked it out and accepted the certificate in spite of leaving out the intermediate and root certificates.
After bundling the certificate, everything worked as expected. I bundled like this
$ cat intermediate.crt >> domain.crt
And repeated for all intermediate and the root certificate.
Had this problem after install Git Extensions v3.48. Tried to install mysysgit again but same problem. At the end, had to disable (please consider security implications!) Git SSL verification with:
git config --global http.sslVerify false
but if you have a domain certificate better add it to (Win7)
C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
It is most likely a missing cert from the server.
Root->Intermediate->Server
A server should send the Server & Intermediate as a minimum.
Use openssl s_client -showcerts -starttls ftp -crlf -connect abc:21 to debug the issue.
If only one cert is returned (either self signed, or issued), then you must choose to either:
have the server fixed
trust that cert and add it to your CA cert store (not the best idea)
disable trust, e.g. curl -k (very bad idea)
If the server returned, more than one, but not including a self signed (root) cert:
install the CA (root) cert in your CA store for the this chain, e.g. google the issuer. (ONLY if you trust that CA)
have the server fixed to send the CA as part of the chain
trust a cert in the chain
disable trust
If the server returned a root CA certificate, then it is not in your CA store, your options are:
Add (trust) it
disable trust
I have ignored expired / revoked certs because there were no messages indicating it. But you can examine the certs with openssl x509 -text
Given you are connecting to a home edition (https://www.cerberusftp.com/support/help/installing-a-certificate/) ftp server, I am going to say it is self signed.
Please post more details, like the output from openssl.
We ran into this error recently. Turns out it was related to the root cert not being installed in the CA store directory properly. I was using a curl command where I was specifying the CA dir directly. curl --cacert /etc/test/server.pem --capath /etc/test ... This command was failing every time with curl: (60) SSL certificate problem: unable to get local issuer certificate.
After using strace curl ..., it was determined that curl was looking for the root cert file with a name of 60ff2731.0, which is based on an openssl hash naming convetion. So I found this command to effectively import the root cert properly:
ln -s rootcert.pem `openssl x509 -hash -noout -in rootcert.pem`.0
which creates a softlink
60ff2731.0 -> rootcert.pem
curl, under the covers read the server.pem cert, determined the name of the root cert file (rootcert.pem), converted it to its hash name, then did an OS file lookup, but could not find it.
So, the takeaway is, use strace when running curl when the curl error is obscure (was a tremendous help), and then be sure to properly install the root cert using the openssl naming convention.
It might be sufficient to just update the list of certificates
sudo update-ca-certificates -f
update-ca-certificates is a program that updates the directory /etc/ssl/certs to hold SSL certificates and generates ca-certificates.crt, a concatenated single-file list of certificates.
I have encountered this problem as well. I've read this thread and most of the answers are informative but overly complex to me. I'm not experienced in networking topics so this answer is for people like me.
In my case, this error was happening because I didn't include the intermediate and root certificates next to the certificate I was using in my application.
Here's what I got from the SSL certificate supplier:
- abc.crt
- abc.pem
- abc-bunde.crt
In the abc.crt file, there was only one certificate:
-----BEGIN CERTIFICATE-----
/*certificate content here*/
-----END CERTIFICATE-----
If I supplied it in this format, the browser would not show any errors (Firefox) but I would get curl: (60) SSL certificate : unable to get local issuer certificate error when I did the curl request.
To fix this error, check your abc-bunde.crt file. You will most likely see something like this:
-----BEGIN CERTIFICATE-----
/*additional certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*other certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*different certificate content here*/
-----END CERTIFICATE-----
These are your Intermediate and root certificates. Error is happening because they are missing in the SSL certificate you're supplying to your application.
To fix the error, combine the contents of both of these files in this format:
-----BEGIN CERTIFICATE-----
/*certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*additional certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*other certificate content here*/
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
/*different certificate content here*/
-----END CERTIFICATE-----
Note that there are no spaces between certificates, at the end or at the start of the file. Once you supply this combined certificate to your application, your problem should be fixed.
According to cURL docs you can also pass the certificate to the curl command:
Get a CA certificate that can verify the remote server and use the
proper option to point out this CA cert for verification when
connecting. For libcurl hackers: curl_easy_setopt(curl,
CURLOPT_CAPATH, capath);
With the curl command line tool: --cacert [file]
For example:
curl --cacert mycertificate.cer -v https://www.stackoverflow.com
Download https://curl.haxx.se/ca/cacert.pem
After download, move this file to your wamp server.
For exp: D:\wamp\bin\php\
Then add the following line to the php.ini file at the bottom.
curl.cainfo="D:\wamp\bin\php\cacert.pem"
Now restart your wamp server.
Try reinstalling curl in Ubuntu, and updating my CA certs with sudo update-ca-certificates --fresh which updated the certs
Mine worked by just adding -k to my curl.
No need to complicate things.
curl -LOk https://dl.k8s.io/release/v1.20.0/bin/linux/amd64/kubectl
Yes you need to add a CA certificate also. Adding a code snippet in Node.js for clear view.
var fs = require(fs)
var path = require('path')
var https = require('https')
var port = process.env.PORT || 8080;
var app = express();
https.createServer({
key: fs.readFileSync(path.join(__dirname, './path to your private key/privkey.pem')),
cert: fs.readFileSync(path.join(__dirname, './path to your certificate/cert.pem')),
ca: fs.readFileSync(path.join(__dirname, './path to your CA file/chain.pem'))}, app).listen(port)
You have to change server cert from cert.pem to fullchain.pem
I had the same issue with Perl HTTPS Daemon:
I have changed:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/cert.pem'
to:
SSL_cert_file => '/etc/letsencrypt/live/mydomain/fullchain.pem'
Enter these two codes to disable the SSL certificate issue. it's worked for me
after a lot of research I found this.
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
On windows I was having this problem. Curl was installed by mysysgit, so downloading and installing the newest version fixed my issue.
Otherwise these are decent instructions on how to update your CA cert that you could try.
My case was different. I'm hosting a site behind a firewall. The error was caused by pfSense.
Network layout: |Web Server 10.x.x.x| <-> |pfSense 49.x.x.x| <-> |Open Internet|
I accidentally found the cause, thanks to this answer.
All is well when I accessed my site from WAN.
However, when the site was accessed from inside LAN (e.g. when Wordpress made a curl request to its own server, despite using the WAN IP 49.x.x.x), it was served the pfSense login page.
I identified the certificate as pfSense webConfigurator Self-Signed Certificate. No wonder curl threw an error.
Cause: What happened was that curl was using the site's WAN IP address 49.x.x.x. But, in the context of the web server, the WAN IP was the firewall.
Debug: I found that I was getting the pfSense certificate.
Solution: On the server hosting the site, point its own domain name to 127.0.0.1
By applying the solution, curl's request was properly handled by the web server, and not forwarded to the firewall which responded by sending the login page.
I intended to comment on Yuvik's answer but I lack enough reputation points.
When you import a .crt file to /usr/share/local/ca-certificates, it needs to be in the correct format. Some of these have been mentioned earlier, but no one has mentioned the need for only a new line character, and no one has collected a checklist, so I thought I would provide one while I'm at it.
The certificate needs to end in .crt. From Ubuntu's man page:
Certificates must have a .crt extension in order to be included by
update-ca-certificates
Certificate files in /usr/local/share/ca-certificates can only contain one certificate
Certificate files must end in a newline. update-ca-certificates will appear to work if each row contains, for example, a carriage return + a newline (as is standard in Windows), but once the certificate is appended to /etc/ssl/ca-certificates.crt, it still will not work. This specific requirement bit me as we're loading certificates from an external source.
On windows - if you want to run from cmd
> curl -X GET "https://some.place"
Download cacert.pem from
https://curl.haxx.se/docs/caextract.html
Set permanently the environment variable:
CURL_CA_BUNDLE = C:\somefolder\cacert.pem
And reload the environment by reopening any cmd window in which you want to
use curl; if Chocolatey is installed you can use:
refreshenv
Now try again
Reason for the trouble:
https://laracasts.com/discuss/channels/general-discussion/curl-error-60-ssl-certificate-problem-unable-to-get-local-issuer-certificate/replies/95548
So far, I've seen this issue happen within corporate networks because of two reasons, one or both of which may be happening in your case:
Because of the way network proxies work, they have their own SSL certificates, thereby altering the certificates that curl sees. Many or most enterprise networks force you to use these proxies.
Some antivirus programs running on client PCs also act similarly to an HTTPS proxy, so that they can scan your network traffic. Your antivirus program may have an option to disable this function (assuming your administrators will allow it).
As a side note, No. 2 above may make you feel uneasy about your supposedly secure TLS traffic being scanned. That's the corporate world for you.
Had that problem and it was not solved with newer version. /etc/certs had the root cert, the browser said everything is fine. After some testing I got from ssllabs.com the warning, that my chain was not complete (Indeed it was the chain for the old certificate and not the new one). After correcting the cert chain everything was fine, even with curl.
This is ssh certificate store issue. You need to download the valid certificate pem file from target CA website, and then build the soft link file to instruct ssl the trusted certifacate.
openssl x509 -hash -noout -in DigiCert_Global_Root_G3.pem
you will get dd8e9d41
build solf link with hash number and suffix the file with a .0 (dot-zero)
dd8e9d41.0
Then try again.
Some systems may have this problem due to conda environment. If you have conda installed then disabling it may solve your problem. In my case when I deactivated conda this curl-SSL error was resolved. On ubuntu or MacOS try this command
conda deactivate
On Amazon Linux (CentOS / Red Hat etc) I did the following to fix this issue. First copy the cacert.pem downloaded from http://curl.haxx.se/ca/cacert.pem and put it in the /etc/pki/ca-trust/source/anchors/ directory. Then run the update-ca-trust command.
Here is a one liner taken from https://serverfault.com/questions/394815/how-to-update-curl-ca-bundle-on-redhat
curl https://curl.se/ca/cacert.pem -o /etc/pki/ca-trust/source/anchors/curl-cacert-updated.pem && update-ca-trust
However since curl was broken I actually used this command to download the cacert.pem file.
wget --no-check-certificate http://curl.haxx.se/ca/cacert.pem
Also if you were having trouble with php you may need to restart your web server service httpd restart for apache or service nginx restart for nginx.
I've been pulling my hair out over this issue for days on a Wordpress installation attempting to communicate with an internal ElasticSearch service via ElasticPress and a self-signed Root CA managed by AWS ACM PCA.
In my particular case, I was receiving a 200 OK response from the default cURL Transport as well as the expected body, but Wordpress was coming back with a WP_Error object as well that ElasticPress was picking up due to this certificate issue but never logging.
When it comes to Wordpress, there are two things worth noting:
The default cURL Transport for all wp_remote_* calls will look to a CA Bundle located in wp-includes/certificates/ca-bundle.crt. This bundle serves largely the same purpose as what's found under https://curl.haxx.se/docs/caextract.html, and will cover most use-cases that don't typically involve more exotic setups.
Action/Filter order matters in Wordpress, and in ElasticPress' case, many of its own internal functions leverage these remote calls. The problem is, these remote calls were being executed during the plugins_loaded lifecycle, which is too early for Theme logic to be able to override. If you're using any plugins that make external calls out to other services and you need to be able to modify the requests, you should take careful note as to WHEN these plugins are performing these requests.
What this means is that even with the right server setup, hooks, callbacks, and logic defined in your theme, you can still end up with a broken setup because the underlying plugin calls execute well before your theme loads and will never be able to tell Wordpress about the new certificates.
In the context of Wordpress applications, there are only two ways I know of that can circumvent this problem without updating core or third-party code logic:
(Recommended) Add a "Must Use" Plugin to your installation that adjusts the settings you need. MU Plugins load the earliest in the Wordpress lifecycle and will be able to give you the ability to override your plugins and your core without directly altering them. In my case, I set up a simple MU Plugin with the following logic:
// ep_pre_request_args is an ElasticPress-specific call that we need to adjust for all outbound HTTP requests
add_filter('ep_pre_request_args', function($args){
if($_ENV['ELASTICSEARCH_SSL_PATH'] ?? false) {
$args['sslcertificates'] = $_ENV['ELASTICSEARCH_SSL_PATH'];
}
return $args;
});
(Not Recommended) If you have absolutely no other options, you can also append your Root CA to wp-includes/certificates/ca-bundle.crt. This will seemingly "correct" the underlying issue and you will get proper verification of your SSL Certificates, but this method will fail each time you update Wordpress unless you bake in additional automation.
I'm adding this answer because I had thought that I was doing something wrong or wonky in my setup for days before I ever even bothered to delve deeper into the plugin source code. Hopefully this might save somebody some time if they're doing anything similar.
Non of the answers mentioned that might be a role to connect to internal vpn i had this issue before and was asking to be on a private network
in my case while I am setting up SSl webserver using NodeJS the problem was because I did not attach the Bundle file certificate , finally I solved the problem by adding that file as following :
Note : code from aboutssl.org
var https = require('https');
var fs = require('fs');
var https_options = {
key: fs.readFileSync("/path/to/private.key"),
cert: fs.readFileSync("/path/to/your_domain_name.crt"),
ca: [
fs.readFileSync('path/to/CA_root.crt'),
fs.readFileSync('path/to/ca_bundle_certificate.crt') // this is the bundle file
]
};
https.createServer(options, function (req, res) {
res.writeHead(200);
res.end("Welcome to Node.js HTTPS Servern");
}).listen(8443)
In the above, replace the text in bold with the following.
path/to/private.key – This is your private key file’s path.
path/to/your_domain_name.crt – Enter your SSL certificate file’s path.
path/to/CA_root.crt – Provide the CA root certificate file’s full path.
path/to/ca_bundle_certificate – This is the full path of your uploaded CA bundle file.
reference: https://aboutssl.org/how-to-install-ssl-certificate-on-node-js/
I had this problem with Digicert of all CAs. I created a digicertca.pem file that was just both intermediate and root pasted together into one file.
curl https://cacerts.digicert.com/DigiCertGlobalRootCA.crt.pem
curl https://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt.pem
curl -v https://mydigisite.com/sign_on --cacert DigiCertCA.pem
...
* subjectAltName: host "mydigisite.com" matched cert's "mydigisite.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
> GET /users/sign_in HTTP/1.1
> Host: mydigisite.com
> User-Agent: curl/7.65.1
> Accept: */*
...
Eorekan had the answer but only got myself and one other to up vote his answer.
I need .pfx file to install https on website on IIS.
I have two separate files: certificate (.cer or pem) and private key (.crt) but IIS accepts only .pfx files.
I obviously installed certificate and it is available in certificate manager (mmc) but when I select Certificate Export Wizard I cannot select PFX format (it's greyed out)
Are there any tools to do that or C# examples of doing that programtically?
You will need to use openssl.
openssl pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt
The key file is just a text file with your private key in it.
If you have a root CA and intermediate certs, then include them as well using multiple -in params
openssl pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt -in intermediate.crt -in rootca.crt
If you have a bundled crt file that you use, for example, with nginx, you can pass that in along with the cert all in one:
cat domain.name.crt | tee -a domain.name.bundled.crt
cat intermediate.crt | tee -a domain.name.bundled.crt
cat rootca.crt | tee -a domain.name.bundled.crt
openssl pkcs12 -export -out domain.name.pfx \
-inkey domain.name.key \
-in domain.name.bundled.crt
You can install openssl from here: openssl
If you're looking for a Windows GUI, check out DigiCert. I just used this and it was fairly simple.
Under the SSL tab, I first Imported the Certificate. Then once I selected the Certificate I was able to export as a PFX, both with and without a keyfile.
https://www.digicert.com/util
The Microsoft Pvk2Pfx command line utility seems to have the functionality you need:
Pvk2Pfx (Pvk2Pfx.exe) is a command-line tool copies public key and private key information contained in .spc, .cer, and .pvk files to a Personal Information Exchange (.pfx) file.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff550672(v=vs.85).aspx
Note: if you need/want/prefer a C# solution, then you may want to consider using the http://www.bouncycastle.org/ api.
You do NOT need openssl or makecert or any of that. You also don't need the personal key given to you by your CA. I can almost guarantee that the problem is that you expect to be able to use the key and cer files provided by your CA but they aren't based on "the IIS way".
SSL Certs for IIS with PFX once and for all - SSL and IIS Explained - http://rainabba.blogspot.com/2014/03/ssl-certs-for-iis-with-pfx-once-and-for.html
Use IIS "Server Certificates" UI to "Generate Certificate Request" (the details of this request are out of the scope of this article but those details are critical). This will give you a CSR prepped for IIS. You then give that CSR to your CA and ask for a certificate. Then you take the CER/CRT file they give you, go back to IIS, "Complete Certificate Request" in the same place you generated the request. It may ask for a .CER and you might have a .CRT. They are the same thing. Just change the extension or use the . extension drop-down to select your .CRT. Now provide a proper "friendly name" (*.yourdomain.example, yourdomain.example, foo.yourdomain.example, etc..) THIS IS IMPORTANT! This MUST match what you setup the CSR for and what your CA provided you. If you asked for a wildcard, your CA must have approved and generated a wildcard and you must use the same. If your CSR was generated for foo.yourdomain.example, you MUST provide the same at this step.
Solution for Windows that doesn't require OpenSSL installed
I recently was trying to solve the same issue - and I only had a windows laptop with no openssl installed (and no enough admin rights to install it). Turns out windows has built-in utility called certutil that is capable of combining .crt and .key files into .pfx. Docs are here.
You need to create a new folder and place you .crt and key files in it. Rename both files to have the same name (but different extension):
{{sitename}}.crt
{{siteName}}.key
In case your key file is a regular txt - just change extension to .key.
After that open cmd in that folder and run certutil -mergepfx [INPUTFILE] [OUTPUTFILE]
Example:
certificate file: mySite.crt
key file: mySite.key
certutil command: certutil -mergepfx mySite.crt mySite.pfx
Note: you will be asked to provide password for newly created .pfx file - don't forget to memorise/store it - as it will be required during certificate import on the target system.
I created .pfx file from .key and .pem files.
Like this openssl pkcs12 -inkey rootCA.key -in rootCA.pem -export -out rootCA.pfx
https://msdn.microsoft.com/en-us/library/ff699202.aspx
(( relevant quotes from the article are below ))
Next, you have to create the .pfx file that you will use to sign your deployments. Open a Command Prompt window, and type the following command:
PVK2PFX –pvk yourprivatekeyfile.pvk –spc yourcertfile.cer –pfx yourpfxfile.pfx –po yourpfxpassword
where:
pvk - yourprivatekeyfile.pvk is the private key file that you created in step 4.
spc - yourcertfile.cer is the certificate file you created in step 4.
pfx - yourpfxfile.pfx is the name of the .pfx file that will be creating.
po - yourpfxpassword is the password that you want to assign to the .pfx file. You will be prompted for this password when you add the .pfx file to a project in Visual Studio for the first time.
(Optionally (and not for the OP, but for future readers), you can create the .cer and .pvk file from scratch) (you would do this BEFORE the above). Note the mm/dd/yyyy are placeholders for start and end dates. see msdn article for full documentation.
makecert -sv yourprivatekeyfile.pvk -n "CN=My Certificate Name" yourcertfile.cer -b mm/dd/yyyy -e mm/dd/yyyy -r
From this links:
https://serverfault.com/a/224127/569310
https://stackoverflow.com/a/49784278/7856894
https://stackoverflow.com/a/17284371/7856894
If you need, use this simple command sequence with OpenSSL to generate filessl.key (SSL certificate key file), and filessl.crt (SSL certificate file):
openssl genrsa 2048 > filessl.key
chmod 400 filessl.key
openssl req -new -x509 -nodes -sha256 -days 365 -key filessl.key -out filessl.crt
Until here you must respond to the interactive form (you can find reference info like req.cnf from this other post: https://stackoverflow.com/a/49784278/7856894)
Then, continue with this last command, which will ask you type the Export Password:
openssl pkcs12 -export -out filessl.pfx -inkey filessl.key -in filessl.crt
Ready, it generated your SSL certificate file in .PFX (or .P12) format: filessl.pfx.
This is BY FAR the easiest way to convert *.cer to *.pfx files:
Just download the portable certificate converter from DigiCert:
https://www.digicert.com/util/pfx-certificate-management-utility-import-export-instructions.htm
Execute it, select a file and get your *.pfx!!
You need to use the makecert tool.
Open a command prompt as admin and type the following:
makecert -sky exchange -r -n "CN=<CertificateName>" -pe -a sha1 -len 2048 -ss My "<CertificateName>.cer"
Where <CertifcateName> = the name of your cert to create.
Then you can open the Certificate Manager snap-in for the management console by typing certmgr.msc in the Start menu, click personal > certificates > and your cert should be available.
Here is an article.
https://azure.microsoft.com/documentation/articles/cloud-services-certs-create/
I got a link with your requirement.Combine CRT and KEY Files into a PFX with OpenSSL
Extracts from the above link:
First we need to extract the root CA certificate from the existing
.crt file, because we need this later. So open up the .crt and click
on the Certification Path tab.
Click the topmost certificate (In this case VeriSign) and hit View
Certificate. Select the Details tab and hit Copy to File…
Select Base-64 encoded X.509 (.CER) certificate Save it as rootca.cer
or something similar. Place it in the same folder as the other files.
Rename it from rootca.cer to rootca.crt Now we should have 3 files in
our folder from which we can create a PFX file.
Here is where we need OpenSSL. We can either download and install it
on Windows, or simply open terminal on OSX.
EDIT:
There is a support link with step by step information on how to do install the certificate.
After successfully install, export the certificate, choose .pfx format, include private key.
Important Note: : To export the certificate in .pfx format you need to follow the steps on the same machine from which you have requested the certificate.
The imported file can be uploaded to server.
When you say the certificate is available in MMC, is it available under "Current User" or "Local Computer"? I've found that I can only export the private key if it is under Local Computer.
You can add the snap in for Certificates to MMC and choose which account it should manage certificates for. Choose Local Computer. If your certificate is not there, import it by right clicking the store and choosing All Tasks > Import.
Now navigate to your imported certificate under the Local Computer version of the certificate snap in. Right click the certificate and choose All Tasks > Export. The second page of the export wizard should ask if you want to export the private key. Select Yes. The PFX option will now be the only one available (it is grayed out if you select no and the option to export the private key isn't available under the Current User account).
You'll be asked to set a password for the PFX file and then to set the certificate name.
I was trying openssl on macbook with libreSSL v2.8.3 and was getting error "No certificate matches private key". I had one domain cert, 2 intermediates and 1 root cert. So I used following command which worked successfully:
openssl pkcs12 -export -clcerts -inkey private.csr.key -in domain.name.crt -certfile intermediate1.crt -certfile intermediate2.crt -certfile root.crt -out domain.name.p12 -name "Your Name"
It will ask for a password that will be used during import. This command will generate a .p12 file which can be renamed to .pfx as both are same.
I was having the same issue. My problem was that the computer that generated the initial certificate request had crashed before the extended ssl validation process was completed. I needed to generate a new private key and then import the updated certificate from the certificate provider. If the private key doesn't exist on your computer then you can't export the certificate as pfx. They option is greyed out.
I would like to promote the "X certificate and key manager" or xca.exe, it's like a GUI version of OpenSSL. With that you can generate the pfx file by the following steps:
Import private key in the "Private Keys" tab;
Import the certificate in the "Certificates" tab;
Generate the pfx file by selecting the certificate and then "Export", select PKCS #12 as the format.
That's it.
In most of the cases, if you are unable to export the certificate as a PFX (including the private key) is because MMC/IIS cannot find/don't have access to the private key (used to generate the CSR). These are the steps I followed to fix this issue:
Run MMC as Admin
Generate the CSR using MMC. Follow this instructions to make the certificate exportable.
Once you get the certificate from the CA (crt + p7b), import them (Personal\Certificates, and Intermediate Certification Authority\Certificates)
IMPORTANT: Right-click your new certificate (Personal\Certificates) All Tasks..Manage Private Key, and assign permissions to your account or Everyone (risky!). You can go back to previous permissions once you have finished.
Now, right-click the certificate and select All Tasks..Export, and you should be able to export the certificate including the private key as a PFX file, and you can upload it to Azure!
Hope this helps!
I've written a small console app which converts a PEM certificate file and a private key file to one .pfx PKCS12 certificate file.
It uses BouncyCastle library.
My Github repo: https://github.com/nklkli/PEM-to-PKCS12
Feel free to modify the code to create password protected *.pfx.
openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx