I have generated my certificate using:
openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt
The certificates have been created.
How do I display the extended validation certificate when I access for example "http://localhost/Web/"
Also note that I am using WampServer
I have generated mt certificated using [OpenSSL]...
How do I display the extended validation certificate when I access for example "http://localhost/Web/"
You can't because its not present.
First, OpenSSL generally conforms to the IETF's standards. There is no concept of extended validation.
Second, extended validation offers nothing by way of security (that is, there are no additional security controls to place that utilize it). EV is also known as "PKI ME Harder". The race to the bottom meant CAs had to stop validating regular certificates correctly because they could not maintain service on the declining profits. EV restores the profit levels and the validations that were always supposed to be occurring.
Third, the extended validation information is in the Cert Policy extension, and the IETF does not require it. See OID for certificates issued under IETF policy? on the PKIX mailing list.
Fourth, extended validation is provided by the CA/Browser Forums in the Extended Validation Guidelines.
Fifth, there is no one OID to cover extended validation. Each CA provides their own OID. See Extended Validation certificate identification.
Finally, OpenSSL does not issue certificates in accordance with the CA/BF EV Guidelines.
If a certificate includes the Cert Policy extension, then you can display it with the following. It prints all the information in a certificate:
openssl x509 -in server-cert.pem -text -noout
Related
Sometimes I test an SSL website on my local machine. I was tired to use a self-signed certificate and add them to my KeyChain on Mac (Browser or other OS). Moreover, Chrome always complains about them. Moreover, this approach was a bit different from the one used in production.
I found this article very useful where you create once your own CA root certificate, add it once to your keychain and then you use the CA private key to sign thousands of SSL test certificate for my local websites.
https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
The tutorial works great but I would like to automate it. For the CA root certificate it was easy, I simply used the option -subj like this:
openssl req -x509 -new -nodes -key /certs/myCA.key -sha256 -days 1825 -subj "/C=$CA_COUNTRY/ST=$CA_STATE/L=$CA_CITY/O=$CA_ORGANIZATION/CN=$CA_COMMON_NAME" -out /certs/myCA2.pem
where the environment variable (CA_COUNTRY, CA_STATE, CA_CITY, CA_ORGANIZATION, CA_COMMON_NAME) are read from an external file.
However, when I tried to replicate the same thing for the website certificate I wasn't able to get the same result. The command is this:
openssl x509 -req -in dev.deliciousbrains.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out dev.deliciousbrains.com.crt -days 825 -sha256 -extfile dev.deliciousbrains.com.ext
It seems that the -subj option doesn't work. Is there a way to pass the info above to this command and avoid interactive questions?
The command you show openssl x509 -req -CA/-CAkey ... does not ask any questions except the key password if there is one (which if you followed the instructions at the linked page there is). It is the preceding command to create the CSR openssl req -new that prompts for the subject name, and for that (like the command for creating the CA cert which is also req but with -x509 -- note -x509 is not the same as x509) you can use -subj. The statement on that page that "your answers don’t matter" isn't quite correct; it is true that when you use SubjectAlternativeName in the leaf cert, as that page advises/directs, the value of Subject is ignored for (at least) HTTPS server identification, but it must (still) be different from the name used for the CA to allow certificate validation to work. Standards allow the Subject name in a leaf cert to be empty when SAN is used (and empty is always different from nonempty and a nonempty name is required in the CA cert) but OpenSSL doesn't handle that case.
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 create self-signed certificate now my problem is Firefox,Safari and even IE will not allow me at all to visit my own page. I can't even click on ignore or similar. It will just block me from visiting mypage.io.
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT certificate is not valid for 81.33.34.123 (fake ip)
My openssl certificate key and crt creation was like this:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout key.pem -out cert.crt
It prompts me to enter some more detail, and I think the problem is where it asks me about "Common Name (e.g. server FQDN or YOUR name)". I answered with www.mypage.io .
It's an unfinished project so I will not buy a certificate yet.
The trust is missing!
Please get a real certificate. You do net even have to buy on: https://letsencrypt.org/ provides them for free.
If you (for whatever reason) stick with your certificate:
IE: Import it to the trusted root certificate authority store (certlm.msc).
Mozilla: Look here
Alternatively please find information on how to generate your own trust chain with open SSL here: How to make browser trust localhost SSL certificate?
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 do have private key(my_ca.key) and public key(my_cert.crt) which is signed by DigiCert. Now I want to generate the SSL certificate (version 3) and sign it by my private key . Here is the way I tried to do that. But when I export into keychain (Mac OS X). I have been getting error like this "This certificate has an invalid issuer keychain". No idea how to solve this. Here my_cert.crt is extended from DigiCert High Assurance CA-3 and that one extended from DigiCert High Assurance EV Root CA. Also added DigiCert High Assurance CA-3, DigiCert High Assurance EV Root CA into keychain. It shows my_cert.crt is valid. How would be getting this kind of error.
######### Initialization
SSL_SUBJ="/C=LK/ST=Colombo/L=Colombo/O=wso2/OU=laptop/CN=mdm.go.com"
########SSL Certificate
echo "\nGenerating SSL Certificate >>>>>> START"
openssl genrsa -out ia.key 4096
openssl req -new -key ia.key -out ia.csr -subj "$SSL_SUBJ"
openssl x509 -req -days 365 -in ia.csr -CA my_cert.pem -CAkey my_ca.pem -set_serial 765644787 -out ia.crt -extensions v3_ca -extfile ./openssl.cnf
echo "\nGenerating SSL Certificate >>>>>> END \n"
openssl pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -CAfile my_cert.pem -name sslcert -passout pass:password
Note: added custom entry in /etc/hosts mapping IP address to SSL certificate CN and for testing server and client are in the same machine.
Download
https://developer.apple.com/certificationauthority/AppleWWDRCA.cer
and double-click to install to Keychain.
Select "View" -> "Show
Expired Certificates" in Keychain app.
Confirm "Certificates" category is selected.
Remove expired Apple Worldwide Developer Relations Certificate Authority
certificates from "login" tab and "System" tab.
Here's Apple's answer.
Thanks for bringing this to the attention of the community and
apologies for the issues you’ve been having. This issue stems from
having a copy of the expired WWDR Intermediate certificate in both
your System and Login keychains. To resolve the issue, you should
first download and install the new WWDR intermediate certificate (by
double-clicking on the file). Next, in the Keychain Access
application, select the System keychain. Make sure to select “Show
Expired Certificates” in the View menu and then delete the expired
version of the Apple Worldwide Developer Relations Certificate
Authority Intermediate certificate (expired on February 14, 2016).
Your certificates should now appear as valid in Keychain Access and be
available to Xcode for submissions to the App Store.
You can also check on https://forums.developer.apple.com/thread/37208
For more detail refer https://developer.apple.com/support/certificates/expiration/
I have got a simple solution for this problem.
Select the certificate in keychain right click it. There you will see the option "GetInfo" click it and select "Trust" option. Select the option When using this certificate to "Always trust". That's all - this certificate will be marked as trusted for your account.
Normally all X.509 certificates in certificate chain except the last one are CA certificates. The first certificate in chain is called root CA (in your case DigiCert High Assurance EV Root CA), then other CA certificates in issuer chain (if any) are intermediate CAs and the last one is End Entity (not CA). I don't think you can issue new SSL certificate issued by non-CA certificate. So you can use my_cert.crt signed by DigiCert as SSL certificate but you cannot issue your own using my_ca.key.