I'm running mono 4.8 and have some trouble with certificates. I know I need to run cert-sync but I can't figure out where the system-ca-bundle.crt is on OSX. The docs for this release, http://www.mono-project.com/docs/about-mono/releases/3.12.0/, only mentions where it is on different linux systems.
You can grab the complete Mozilla CA certificate store in PEM format from:
https://curl.haxx.se/docs/caextract.html
Buyer beware: Downloading and blindly adding CA Root Certificates should set off bells, alarms, and whistles. The cacert.pem they provide is SHA256 marked and you can compare it to Mozilla's
https://hg.mozilla.org/releases/mozilla-release/raw-file/default/security/nss/lib/ckfw/builtins/certdata.txt
That said, you can always extract the individual CA certs you need from that PEM and verify each one, etc.... Or blindly add them all:
curl --remote-name --time-cond cacert.pem https://curl.haxx.se/ca/cacert.pem
cert-sync --user cacert.pem
Set BoringSSL as Mono's TLS provider and enjoy:
export MONO_TLS_PROVIDER=btls
Related
The Keytool commands for Tomcat SSL includes self-signed certificates which doesn't work with my CA certified cert. I tried creating keystore and importing it with root, intermediate and server cert. On changing the connector port in Tomcat/conf/server.xml started tomcat server but browser URL not reflecting that URL is safe/certificate chain.
openssl pkcs12 -export -in mycert.crt -inkey mykey.key -out mycert.p12 -name tomcat -CAfile myCA.crt -caname root -chain
This is the command provided in Apache document, but how to import intermediate certificate in this command?
Meta: this isn't really a programming or development question. Plus I'm pretty sure it's partly duplicate because I remember writing most of this answer before, but I can't find it now; if I do later I will add.
First, to be clear, changing the port in a Tomcat <Connector> doesn't enable SSL/TLS (HTTPS). Enabling SSL/TLS requires changing several other attributes and (usually) elements in the <Connector>, and does NOT require changing the port, although you often (probably usually) do change both together.
Also, you need the intermediate cert(s) for a proper SSL/TLS server but you don't need the root cert. All SSL/TLS standards explicitly allow the server to omit the root cert from the chain transmitted in the handshake, most non-Java servers do so, and all clients I have ever seen accept it. The Java KeyStore capability was designed to support multiple applications and not just SSL/TLS, so to be safe keytool encourages you to include the root, but with other tools like OpenSSL it's easy to omit it. OTOH if you want for some reason to include it, that's permitted and does work.
(To be pedantic, it's actually the (trust) anchor not the root. Traditionally the anchor was expected to be the root, but over time it has developed that it might not. RFC8446 for TLS1.3 in 2018 is the first SSL/TLS specification to reflect this, and even there it's extremely rare, so I will ignore it.)
Answer: to include chain and/or root cert(s) in a PKCS12 file created with OpenSSL commandline, there are two approaches:
manually determine the correct/desired cert(s) and supply them in either the -in option (which defaults to stdin, which in turn can be piped from e.g. cat) or -certfile (specifying a file containing one or more cert PEM blocks)
specify -chain and provide in the working truststore at least the correct cert(s). OpenSSL will automatically select the cert(s) that chain from the leaf cert, ignoring any others.
As with nearly all commandline operations, the working truststore can consist of -CAfile which is a file (only one) containing any number of cert PEM blocks; or -CApath which is a directory containing any number of files each containing one cert PEM block and with a name (or symlink) based on the subject hash, as described in the man page for c_rehash(1) on your system ((1ssl) or similar on some) or on the web; or both.
If -CAfile -CApath are not specified, and not suppressed by -no-CAfile -no-CApath (in 1.1.0 up only), they default to a file and directory configured at compile time, but upstream does not supply any contents for such a file and/or directory. Linux distros I am familiar with all build OpenSSL to use locations in /etc somewhere (but they vary as to where) and have a package named something like ca-certificates that provides default contents for the default truststore location(s), and may provide a way to change those contents. For example on RedHat-family see update-ca-trust and on Debian-family see update-ca-certificates.
Alternative: for Tomcat 9 (and 8.5) you don't need a keystore. Older versions of Tomcat required you to match the SSL/TLS implementation to the configuration: Java (JSSE) required a Java keystore while 'tcnative' (aka APR = Apache Portable Runtime) required OpenSSL-style PEM files. Modern Tomcat allows you to use either type of configuration with any SSL/TLS implementation, so you can simply use mykey.key mycert.crt intermediate.crt in the <Connector> or better the now-preferred <SSLHostConfig> and <Certificate> sub-elements; see http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support . If you are going by http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html be warned that hasn't been kept up to date and a number of details in it are wrong, although the basic ideas are mostly still valid.
jww's answer to the question "How do you sign a Certificate Signing Request with your Certification Authority?" Original question was very useful to me and I created my own CA key and cert and used it to sign a server cert.
I have a linux server that I want to reach from an MS Edge browser. I found that the Microsoft Management Console application would not accept the .pem format certs so I converted them into .p12 (PKCS12) format and combined them in a single file also using material that I found on the stackoverflow site. (file attached)
My question is does openssl create pkcs12 certs natively or is the conversion stage necessary?
I found this service https://whatsmychaincert.com/ that generate a chain (with the root) by pasting a certificate.
There is any way for generate the chain with OpenSSL?
I have found this command:
openssl s_client -connect example.com:443 -showcerts
that show all certificate chain, but requires that the certificate is already online.
there is any way for generate the chain with a local file certificate?
s_client -showcerts shows the chain as provided by the server; this should be the full chain optionally less root, but as that website says some servers aren't configured correctly. It also has a link "How does this work" which as one might expect explains how it works:
mkcertchain is a utility for building a chain of intermediate certificates
for an SSL certificate. It downloads the chain certificate from the URL
specified in the certificate's "CA Issuers" field, recurring until
encountering a root certificate that's trusted in all major browsers.
If multiple certificate chains are found, the shortest one is used.
Given a starting cert in a file, or outputtable by some program (such as perhaps a database query), in either PEM or 'DER' (binary) format, openssl x509 -text [-inform pem|der] outputs all of the cert data including 'CA Issuers'. Any number of text-handling programs like awk, perl, grep, shells such as bash, or PowerShell, should be able to extract that line and its value, and since it is normally http:, any number of HTTP-request programs like curl and wget can fetch the cert. Any scripting language like perl, shell or PowerShell can iterate this process as needed, stopping when a root is hit by comparing Subject and Issuer. If you want to stop at an anchor that is not a root that's a little more complicated, but I don't think any such anchors are currently accepted by major browsers, thus aren't needed for the purpose of building a chain to be accepted by browsers.
FWIW, even if your certs don't have the CA Issuers field in AIA, most public CAs including intermediates have now been captured by the certificate transparency logs, which are easily searchable at https://crt.sh ; you can easily navigate through the chain just by clicking links so I haven't thought about trying to automate it, although presumably the numerous tools that 'drive' or simulate a web browser to interact with a website would work here.
And of course, the CA that issued your cert in the first place should always be able to supply the needed chain certs; it's part of their job.
I'm working on a demo in Worklight version 6.0 where I need to use SSL from iOS and Android to the Worklight Server.
Is there any way to use a self-signed or test certificate in the Worklight server? Or do I need to buy a certificate from one of the standard CAs even for test/demo?
I've seen references to how to import my certificate in the Android system trust store, and that looks promising, but I'm not seeing anything equivalent for iOS. There are a number of native code workarounds (which net out to disabling SSL certificate verification altogether) along with much discussion about which solution works/doesn't work (and no discussion of what still works on iOS 7 that I can find).
Is importing the certificate into the Android system truststore the best approach for development?
Is there a simple solution for iOS that allows for self-signed or test certificate that doesn't disable certificate checking entirely?
OK. I didn't find a general purpose answer, or a way to accept a particular certificate, but on iOS and Android, it is possible to disable client side certificate validation for development and test.
In Android, the default Manifest is already configured to ignore certificate validation. By default, the Application element in AndroidManifest.xml has an attribute:
android:debuggable="true"
With this setting, the client does not validate the SSL certificate presented by the server. So on Android, self-signed certs just work by default. The important thing to keep in mind is that when you move from development to production, it is important to set this attribute to false. When the attribute is set to false, the client validates the cert presented by the server, and so you will need a real signed cert for the production server. (makes sense)
In iOS, there are several proposed solutions, The one I'm using is to add the following to the end of my < App Name >.m file:
#implementation NSURLRequest(DataController)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
#end
From what I gather, this is a unpublished API, and overriding it is bad form, but it works, and this is only for development, so I'm going with it.
I suppose I could be clever, and check for the hostname of my Worklight Server before blindly returning YES, but in any case, the addition of the code above does allow my app to use SSL with a self signed cert at the worklight server.
Both of these "solutions" need to be removed before the app is put into production, as they leave the app vulnerable to a man-in-the-middle attack. But for development/early test/demo they allow SSL without having to get real signed certificates.
There is a very easy way to use certificates not signed by a known CA for development and test purposes.
Note that this support does not come from Worklight. It is really up to each mobile platform to allow you to establish trust for these type of certificates or not. The recommendations given by David above, are really just workarounds to disable SSL validation, which could be a valid alternative in some cases. However, the android:debuggable flag will only get you so far as it doesn't cover certain scenarios like when directUpdate is enabled. Plus disabling all forms of SSL validation, may not be what you really want even in dev/test environments.
Here is what you can do:
First understand that pure self signed certificates won't work on iOS and Android, just because the platforms themselves do not allow you to install these type of certificates into their truststores.
Use self signed CA certificates instead. These are just as easy to create. They are the same as self signed certs except that they have the CA bit enabled to TRUE.
Beware, that self signed certs generated by some tools do not usually create certificates that are also CAs. Ensure your self signed cert is a CA as well.
OpenSSL example on how to create a self signed CA cert:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
Ensure the certificate.crt file is X.509 version 3, and has the following extension defined: basicConstraints = CA:TRUE
You can check the certificate.crt file by running the following command:
openssl x509 -in certificate.crt -text -noout
Use this certificate as your server certificate.
On iOS, e-mail your certificate.crt file or host the file on a web browser where you can manually click on it to install it. (Don't install it directly from the hosting WL server, as this only imports it into the browser space and not the device.)
Check that it gets installed by looking under Settings->General->Profiles->Configuration Profiles
Ensure iOS recognizes it and marks is as 'trusted'
On Android you can install the certificate.crt in the Android CA Store. The certificate.crt can be placed in /sdcard, and can be installed from Settings > Security > Install certificate from SD card. The certificate can also be opened by sending it as an email attachment or downloading via browser as in step 7 above. Android asks for an alias for the certificate, choose any name.
Check that it gets installed by looking under Settings -> Security -> Trusted Credentials ->User
Yes, you can achieve this by doing the following:
Create a self signed certificate that will act as a certificate authority.
Install this certificate on the iOS device (easiest way for me to do this was to host the certificate on a server and visit the link in safari and then download it). The iOS device will now trust any a server with a certificate that has been signed by this certificate authority
Create a new certificate that is signed by the certificate authority you created in step 1.
Use this newly signed certificate on your Worklight server
Currently Worklight App not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.
The service I need to connect to has provided me three files and I'm trying to figure out what I need to create the Cert=xxx.PEM file that STUNNEL needs
I have a "keystore.jks" file. Dumping that with keytool says it's a "Private key entry"
I have a "truststore.jks" file. Dumping that says it's a "trusted certificate entry". The alias is "server"
I also have a "xyz.cer" file. That seems to be a X.509 certificate
I've got OPENSSL and a Java program called "KeytoolUI".
Bottom line is I have a bunch of files and tools and with not much knowledge of SSL I feel like I can't see the wood for the trees. Do I need all those files? The existing PEM files I have for other services just have a "Certificate" section and a "RSA Private key" section.
Any advice appreciated. Thanks!
It sounds like your provider has provided your keypair (for client side authentication) as a java keystore, and (I'm guessing) the remote server's public certificate or CA certificate in PEM format.
That's some fairly heavy guesswork, but it's strange that they've sent you a private key if you aren't doing client side auth. (Let's hope they haven't sent you the private key for their server!).
As far as I'm aware, stunnel only uses PEM certificates, so you will need to convert your JKS files into two PEM files (one for the private key, one for the public certificate). One way to do this is to convert the JKS to a PKCS#12 (aka PFX) file using keytool, and then use OpenSSL to convert the PKCS#12 files into PEM private key/certificate files.
Once you have these two files, use them with the key and cert options in stunnel.conf.
For the final (mystery) PEM certificate that you have, I'm going to guess (again) that this is the remote CA, and therefore that you should configure this against the CAfile parameter in stunnel.conf. (If it's appropriate for you to post details here, edit to include output from openssl x509 -in <filename> -text to provide more clues).
No answer I'm afraid. In the end I got the company to just send me a PEM file.
I did find quite an authoritative looking tutorial here
http://www.herongyang.com/crypto/Migrating_Keys_keytool_to_OpenSSL_2.html
The problem is for somebody who doesn't do this everyday getting a bunch of free/open source software from various sources to work together. You can find scripts to do this on various sites, but when you run them, you'll see Java tracebacks, complaints about LIBEAY32.DLL missing ordinals, etc., etc.
If you get the exact right versions of KEYTOOL, OPENSSL, etc.,, installed in the correct place, with the exact right JRE version and all the other DLLs, the PATH correct, and all the stars exactly lined up you'll be fine. Until then it's just an exercise in frustration.
openssl x509 -inform der -outform pem < xyz.cer > xyz.pem