I'm using a Microsoft Certification authority to sign some certificates from a corporate network. Using the certreq utility everything works fine, but I didn't found the purpose of the template anywhere.
In my case, I need to create some certificates requests in a Linux server (using OpenSSL) and then sign it using the Microsoft CA in another server (Windows Server 2012). The proccess is basicaly described below:
Create the .csr file and key in a Linux server (openssl req -newkey rsa:1024 -keyout myKey.key -out myCsr.csr -subj /CN=mydomain.com/O=Organization/C=US/ST=ST/L=City);
Send the csr file to Windows Server where the CA is installed;
Call certreq utility to create the certificate itself (certreq -submit -attrib "CertificateTemplate:MyWebServerTemplate" -config DOMAINCA\CA1 myCsr.csr myCert.cer);
When needed, send the cert to Linux again and convert the .cer in a .crt with the command openssl x509 -outform DER -in myCert.cer -out myCert.crt. This is needed when certreq is used with -binary option
As far I know, the choose of the template is mandatory but anything changes no matter which I choose. I tried to select many templates, but apparently anything changes
update:
After some tests, I noted that some templates actually changes some original info from CSR, but my question still is: What is the purpose of the template, since the info is all in the CSR, and why is it mandatory? How can I force the MS CA to use the CSR info?
I'm new on this certificate administration thing. Am I misunderstood something in the process?
Related
I'm having problems understanding the difference between files produced by openssl and how to detect them.
For example I'm trying to generate Self-signed cert with private key and generate JKS file from p12
format. I'm googling like a madman but I still don't know how to generate it correctly to be able to use following commands.
openssl pkcs12 -export -in user.pem -inkey user.key -certfile user.pem -out testkeystore.p12
keytool -importkeystore -srckeystore testkeystore.p12 -srcstoretype pkcs12 -destkeystore wso2carbon.jks -deststoretype JKS
Source: https://www.ibm.com/support/pages/how-generate-jks-keystore-existing-private-key
I found a couple of different commands to generate Self-signed cert and private key but I don't know how to map resulting files to the commands above and whats worse I don't understand what those commands do.
I mean I see what files they generate and understand that certificate and private key used to sign it ( or maybe the other way around :| ) but what is the difference between those commands and is cert.pem === certificate.crt - Those file extensions are driving me crazy.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
This is yet another situation where I'm having similar issues with the openssl command. At this point I'm even ready to read some RFC ( I hope it won't come to this :) )
Thanks in advance for help
Those file names represent different parts of the key generation and verification process. Please note that the names are just convention, you could just as easily call the files pepperoni.pizza and the content will be the same, so do be conscious of how you use the filenames.
A brief primer on PKI - Keys come in two halves, a public key and a private key. The public key can be distributed publicly and widely, and you can use it to verify, but not replicate, information generated using the private key. The private key must be kept secret.
.key files are generally the private key, used by the server to encrypt and package data for verification by clients.
.pem files are generally the public key, used by the client to verify and decrypt data sent by servers. PEM files could also be encoded private keys, so check the content if you're not sure.
.p12 files have both halves of the key embedded, so that administrators can easily manage halves of keys.
.cert or .crt files are the signed certificates -- basically the "magic" that allows certain sites to be marked as trustworthy by a third party.
.csr is a certificate signing request, a challenge used by a trusted third party to verify the ownership of a keypair without having direct access to the private key (this is what allows end users, who have no direct knowledge of your website, confident that the certificate is valid). In the self-signed scenario you will use the certificate signing request with your own private key to verify your private key (thus self-signed). Depending on your specific application, this might not be needed. (needed for web servers or RPC servers, but not much else).
A JKS keystore is a native file format for Java to store and manage some or all of the components above, and keep a database of related capabilities that are allowed or rejected for each key.
The commands you list look fine to me, and I don't see a question beyond asking what the different files are for. If you need more information, please enrich your question.
.key is the private key. This is accessible the key owner and no one else.
.csr is the certificate request. This is a request for a certificate authority to sign the key. (The key itself is not included.)
.crt is the certificate produced by the certificate authority that verifies the authenticity of the key. (The key itself is not included.) This is given to other parties, e.g. HTTPS client.
.pem is a text-based container using base-64 encoding. It could be any of the above files.
-----BEGIN EXAMPLE-----
...
-----END EXAMPLE-----
.p12 is a PKCS12 file, which is a container format usually used to combine the private key and certificate.
There isn't only one extension. For example you may see certificates with either the .crt or a .pem extension.
Just to add more info: .der, another (binary) encoding (either public or private key, or csr)
I am generating a simple self-signed certificate via a simple PowerShell script leveraging openssl and then use the pfx certificate in a simple ASP.NET Core 2.0 application for enabling HTTPS)
function New-SelfSignedCertificate([string] $BaseName = 'localhost', $CommonName = 'localhost', [UInt16] $DayCount, [string] $Pass = 'somepassword')
{
&openssl req -new -x509 -newkey rsa:2048 -keyout "$BaseName.key" -out "$BaseName.cer" -days "$DayCount" -subj /CN="$CommonName" -passout "pass:$Pass"
&openssl pkcs12 -export -password "pass:$Pass" -passin "pass:$Pass" -out "$BaseName.pfx" -inkey "$BaseName.key" -in "$BaseName.cer"
Remove-Item -Path "$BaseName.key"
Remove-Item -Path "$BaseName.cer"
Remove-Item -Path '.rnd'
}
The problem of my certificate is that it triggers a lot of warnings on every browser: Chrome, Opera, Firefox (e.g. SEC_ERROR_UNKNOWN_ISSUER), IE11 (e.g. DLG_FLAGS_INVALID_CA) and Edge (DLG_FLAGS_INVALID_CA and DLG_FLAGS_SEC_CERT_CN_INVALID), is there anything I can do at the generation to avoid those warnings? (i.e. besides adding manually the certificate to the Trusted Root category)
Seems the issuer cannot be identified, I mean how can the certificate can be judged in way that the browser would say without a user intervention: "ok you can go to the Trusted Root Certificate Authorities."? (i.e. looking for convenience during development stage).
is there anything I can do at the generation to avoid those warnings? (i.e. besides adding manually the certificate to the Trusted Root category)
Either you don't understand the concept behind trusting a certificate or I don't understand your problem. The main idea behind the certificate validation is that the browser will detect if some hacker is diverting or intercepting your connection in order to impersonate some trusted site or to sniff sensitive (encrypted) data during a man in the middle attack.
If anybody could automatically add a CA or a certificate as trusted to the browser, i.e. without any notice to the user, then anybody could create a certificate for an arbitrary web site (like paypal.com, google.com..) and use this inside such an attack without the browser being able to detect the attack.
I mean how can the certificate can be judged in way that the browser would say without a user intervention: "ok you can go to the Trusted Root Certificate Authorities."?
This can not be set in any way by the certificate itself. Only the user or administrator or the developer of the system/browser can decide if a new CA should be considered trusted.
I have an existing MQ MQI connection (Server-Connection) between an HP Nonstop and a Windows server. I am working on configuring the queue manager for SSL on the Nonstop.
I have followed a couple sources available on net closely but am still confused about a few things.
The Stash.sth file, I have not gotten the following command to work:
openssl pkcs12 -export -in cert.pem -inkey server_key.pem -out personal_cert.p12 -passin pass:certkey -password pass:certkey -chain -CAfile trust.pem
I get an "Error unable to get local issuer certificate chain."
The SSLUpdate.pdf document that is delivered with MQ mentions creating the Stash.sth file using:
amqrsslc -s cert (cert being the trusted certificate store), and this DOES work for me.
However, it also says "The amqrsslc command will prompt for the private key pass phrase used when creating the certificate/key pair and will write a masked copy of that pass phrase to the Stash.sth file"
If I should have specified the same pass phrase earlier, where should I have done that?
When I created the private key? Should I have specified a -passin or -passout parameter? All I used was openssl genrsa -out privatekey.pem 2048 -sha256
Or, when I generated the certificate request? There is a prompt to enter an optional password.
Or neither? Is the pass phrase used when creating the Stash.sth file completely arbitrary?
Thanks for any help!
The error usually means the list of trusted certificates is not complete.
I think you need to be sure you certificate chain is complete.
Here is from the technote:
If the certificate request is signed by an intermediate certificate, the
certificate chain for the signed personal certificate will need to be
added to the trust.pem file. You need to add the root certificate and
the intermediate to the trust.pem file. Review create_trust_file.sh
script for the syntax.
I also think this presentation document may be helpful to you.
http://www-01.ibm.com/support/docview.wss?uid=swg27023472&aid=1
I deployed the IBM app center on IBM worklight server 6.1 and enabled the SSL by generating SSL certificate using Liberty core's common utility and updated the server.xml according to that.
When I am accessing the link https://< serverIP >:< sslPort >/appcenterconsole/inst.html
It shows SSL error SSL certificate not matches the server URL this is my first problem.
On chrome it shows an option to proceed anyway after that I am able to access the page which has IBM App Center installer application using my username and password.
But when I click on the link of the application to download and install the app it shows message that Cannot connect to < serverIP > this is my second problem
You generated a self-signed certificate. Per documentation, IBM Application Center does not support self-signed certificates. You need to purchase an official SSL certificate from a certificate authority. This limitation comes actually from iOS.
There is a complex workaround, but I recommend this only for testing. The workaround is not really suitable for production:
Generate a special self-signed certificate with CA flag set to true. This makes the certificate also a certificate authority. Note: Most instructions on the web are only valid for self-signed certificates with CA flag set to false. If you use openssl, use the options -reqexts v3_req -extensions v3_ca
Import this SSL certificate into your device. See here and in its subsections for details. This should also work for 6.1 even though the documentation link is for 6.2
Install this certificate for your webserver and proceed as usual.
You dont need to purchase nothing, you just need to create a CA certificate with an apple mac, install it to the device and u will be allowed to download the apps, easy peasy
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out cerficate.crt -reqexts v3_req -extensions v3_ca
put your domain in the name field when required.
then
cat cerficate.crt privateKey.key > server.pem
then
openssl pkcs12 -export -in certificate.crt -inkey server.pem -out server.p12 -passout pass:passServerP12 -passin pass:passServer
Then to try it out:
openssl s_client -connect hostname:port
Hope i could help ;D
I'm trying to connect to a web service (not under my control) configured to authenticate users via SSL client certs. I have a valid certificate in PKCS12 format containing the client certificate and associated private key. The certificate is issued by a CA accepted by the web service provider.
Installing the certificate and trying to access the restricted area in various browsers gives the following results:
IE6 - Works fine and I can retrieve the WSDL
IE7 - Prompts for the certificate but then fails with a 403.7 from the server
Firefox3 - Set to ask, but no prompt and fails with a 403.7
Safari 4 - Certificate is installed in the Keychain, but no prompt and a 403.7
Also, trying to access the web service programmatically (Java) fails with the same 403.7 error code.
Strange that this works in IE6 but in no other browser, what am I missing? Do I need to include the full CA certificate chain in the PKCS12 file?
Any help would be greatly appreciated.
This really works! If you're confused by the -inkey and -in options, they are the private key and certificate from the p12 file. You can convert the p12 file to pem format with:
openssl pkcs12 -in file.p12 -clcerts -out file.pem
and use the above command with "-in file.pem" only.
Also, you can import the root CA cert into your trusted certs store, here is the description how to do that: http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl, and then you don't have to manually copy the certificates. After installing the cert use the command above without the "-CAfile chain.pem".
Ok, got this working. The answer is yes, I did need to include all intermediary CA certs in the PKCS12 file. I concatenated all the intermediary CA certs plus the Root CA cert in the file "chain.pem" then executed the following command:
openssl pkcs12 -export -chain -CAfile chain.pem -in cert.pem -inkey key.pem -out cert.p12