Trying to set up one-way SSL with Weblogic 11g and running into an issue. I have a custom identify (my own cert) but I only want to do one-way SSL, so why do I need to specify the trust key store? (I have no use for trust as I am only doing one-way SSL where my server presents its cert to the client).
Can someone please explain this? It seems like to get this to work I must choose Custom Identify and Java Standard Trust, even though the CA certs in the Java Standard Trust keystore will never be used for anything. I tried to do Custom Identiy and Custom Trust and left trust keystore blank and received errors on startup related to the trust keystore field not being populated.
You don't need to specify the trust key store, except for the fact it is looked for if you specify Custom Trust. So therefore you do, or use JavaStandardTrust or DemoTrust instead.
It is dangerous using DemoTrust as anyone with an Oracle installation could potentially get trusted by you, so I would go with the JavaStandardTrust in your case.
The other option is to go with CustomTrust and create an empty keystore for that, apart from the actual key in it. In that way you implicitly trust no-one.
Related
I have bought a domain and certificate from Azure. The certificate is given by Go Daddy as azure partner and it is signed with the intermediate certificate from Go daddy hence it always needs chaining of certificates till Root CA.
Our website is used as a REST interface for our customers and hence clients use Java SDK or plain scripts. In our case precisely with zulu jdk image(11u5-zulu-alpine) from microsoft and even I tried with ubuntu 16.04 LTS and get the same error.
if we try to even curl to our site with proper certificates we get error as below and its because of the intermediate CA is missing!
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
With java SDK we get as javax.net.ssl.SSLHandshakeException
I have 3 questions.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
And lastly I have a fair idea of how certificates work w.r.t client and server but with the intermediate CA in picture I am unable to understand exactly where the intermediate CA should be put in. I read few posts on the SO but its still unclear. Please bear with me and if some one can explain me the approach how it works in general and what could be the good practice.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
You should definitely configure the server to send all required intermediate certs; this is required by the TLS standards. (Although if you don't, clients have the option to try to obtain them by other means, like a cache or repository or AIA, and sometimes they do.) Whether the server sends the root is optional; the standards actually state this in reverse, by saying the server MAY omit the root, where the all-caps 'MAY' invokes the meaning defined in RFC 2119. E.g. for TLS1.2 in RFC5246 7.4.2:
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
How you do this depends on what web-server software you are using, which you didn't identify. Although from the fact you specify a Java version, I can speculate it might be Tomcat, or something based on Tomcat like Jboss/Wildfly. Even then, Tomcat's SSL/TLS configuration varies substantially depending on the version and which type of connector 'stack' you use (the pure-Java JSSE, or Tomcat Native, aka APR Apache Portable Runtime, which is actually OpenSSL). However, a 'pfx' (PKCS12) file can definitely contain both a privatekey and the matching (EE) certificate PLUS the chain cert(s) it needs, and is a convenient way to deal with the whole kaboodle at once.
For a cert obtained directly from GoDaddy, they provide instructions linked from https://www.godaddy.com/help/install-ssl-certificates-16623 for many common servers. I don't know if for Azure they use any different chaining that would alter these instructions.
If your server is publicly accessible, at port 443, https://www.ssllabs.com/ssltest will check if it is correctly handling the chain certs, as well as many other things. There are other tools as well but I am not familiar with them; for non-public servers I usually just look manually.
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Clients should not install intermediate cert(s) because as above the server should send them. The GoDaddy roots have been accepted in most official truststores for several years now, so most clients using default settings should not need to add them. However, some might; in particular Ubuntu 16.04 might be old enough that it doesn't have GoDaddy preinstalled. And any client(s) that wishes to use a customized truststore, and/or a pin, must ensure that it is set to include/allow your cert's trust chain.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
GoDaddy has supplied its roots to (AFAIK all) the major truststore programs, as above. IINM Ubuntu uses the Mozilla/NSS list, which definitely includes GoDaddy today, but as above I can't be sure about 16.04. I don't know for alpine. CAs do not request truststore programs to include intermediates (although a program or user may be able to add selected intermediate(s) as trusted, depending on the software used).
I'm trying to modify my Go client and server code to use TLS. In Python I can do ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
which will automatically load the system's trusted CA certs and uses secure settings. I'm wondering if there's something similar in Go where it will automatically load trusted CA certificates. I'm not sure exactly what to put for the client's certificates.
I think you're looking for tls.Config. But keep in mind that Python's ssl.create_default_context exposes a lot of SSL internals that most people don't need, and you might not need a tls.Config in your application at all. For instance, net/http has a http.ListenAndServeTLS() function which starts a TLS web server with sensible defaults and whatever certificates you provide.
Let us say, I used a queue manager QMGR1 in host1 to create a CSR and obtain a CA-verified certificate labeled ibmwebspheremqqmgr1. Can I use load the same certificate (and its root and intermediary chains) in another host host2 for the a queue managed named same (i.e. QMGR1) ? In other words, a certreq needs to be present when we 'receive' a certificate using rumqakm or no? Can we just 'add' a cert (like we do the chains)? If the question is not clear, please ask, i can provide more details. In my case host2 is production. host1 is a QA environment where we test connectivity. Thanks.
Update question from comments 26DEC16
Specific to MQ, I believe I would have to load CSR first on host2 and then receive the CER again, right? I wonder how do I 'load' the CSR without creating it. I see an option to recreate it in runmqakm, never used that before and not sure if that will work.
TL;DR: Yes.
When you create a CSR using IBM GSKit (e.g. runmqakm), the result is a certificate that is unsigned and the CSR file itself. The CSR is cryptographically bound to the unsigned certificate that remains in the .rdb file of the keystore. The signed CSR cannot be received into just any keystore at that point.
When you receive the signed CSR, it is combined with the pending unsigned certificate and moved to the .kbd file of the keystore. At this point it is a valid personal certificate with the label name you specified (ibmwebspheremqqmgr1 in this case) and the DN that you specified.
Once completed you have a usable personal certificate. If you wanted to use it on another QMgr you would need to get that certificate to that other QMgr in one of two ways:
Copy the set of files that comprise the keystore.
Export the personal certificate to a file and then import that file into the other QMgr's keystore.
If you copied the entire keystore and the other QMgr is also named QMGR1 then you can use them immediately. If the other QMgr has a different name, then you'd have to rename the certificate to something other than ibmwebspheremqqmgr1, or in a modern QMgr set the QMgr's CERTLABL attribute to ibmwebspheremqqmgr1. Generally, you want the cert label to reflect the name of the QMgr using it so a QMgr named QMGR2 with a CERTLABL of ibmwebspheremqqmgr1 is not recommended.
If you import the certificate then you can set the label during the import command.
Keep in mind, the label and the Distinguished Name are two completely different and unrelated things. The distinguished Name is the value that the CA verified and signed off over and is cryptographically bound tot he keys in the cert. It is the thing that a remote connection partner decides whether to trust or not.
The label is how the local QMgr or client finds its own certificate. Imagine you had created two personal certificates, the QMgr needs to know which one to send. It finds the correct one by matching the label of the certificate to the expected value of ibmwebspheremq[qmgr name in lower case] or against the QMgr's CERTLABL attribute if it is not blank.
This is why the certificate label can be changed easily with a GSKit command but the Distinguished Name is immutable.
With this in mind, note that external, and many internal, CAs will expect the certificate Common Name of the certificate to contain the fully-qualified hostname where the certificate will be used. HTTPS clients check that the certificate CN matches the hostname when they connect. For an MQ connection, this is not the case. You can put anything in the CN that your CA will sign and use it on a QMgr of any arbitrary name. So your certificate can have CN=QMGR1 and that QMgr can live on mqhost.yourcompany.com and MQ likes it just fine. However, clients using the new MQ REST API will not! This is an important distinction for people hoping to use the new MQ REST API.
Finally, please note that best practice is to generate the certificates where they will be used, protect them using filesystem permissions, keep them in local storage, and never copy or move them from that location. Public/Private key crypto was invented to solve the very difficult problem of securely exchanging private keys. If the personal certs are copied around it defeats the purpose of using them in the first place.
The various commercial PKI packages (i.e. IBM Tivoli Key Lifecycle Manager, Venafi, etc.) all solve this problem using FIPS-certified algorithms that don't store keys or crypto primitives on disk, securely wipe memory space before releasing it, and in general take excruciating care to not leave keys unprotected in transit, disk or memory. If you must copy personal certs around, use a real PKI package designed for that purpose if the company has one. Otherwise, export them to a .p12 with a very long and random password and avoid email, FTP, or other non-secure means of copying the file around.
Context:
I have an application that is deployed to each client as a Virtual Machine. The latter is installed by the clients wherever they want (I don't necessarily know the final domain). The application comprises an JBoss Web Server that provides access to a configuration page, protected by SSL. Right now the server is using a self signed Certificate. However, I want the browsers to stop showing the warning messages associated to self signed certs. Moreover, I provide a free version of the application that has basic functionality.
Question:
For cases where the client is using a free version (and me wanting to reduce costs), what is the best approach when using a SSL cert, and not knowing the final domain (most of the time)?
It is acceptable to use a self-signing cert? If so, a different one
per client install?
Is it best to issue a new cert (maybe a free one) for each
deployment?
Is is acceptable to use the same cert, signed by a proper CA, on all
of the deployment VMs?
A completely different approach?
Thanks guys!
It is acceptable to use a self-signing cert? If so, a different one per client install?
Ask your clients. Will they put up with a browser warning? or not?
Is it best to issue a new cert (maybe a free one) for each deployment?
It is best for the client to acquire his own SSL certificate. You can't do that for him. Nobody can.
Is is acceptable to use the same cert, signed by a proper CA, on all of the deployment VMs?
No, it entirely defeats the purpose. The certificate and the private key it wraps are supposed to uniquely identify the holder.
A completely different approach?
Handball the whole megillah to the clients. Self-identification is their problem, not yours.
I am new to TLS/SSL so this might be a very basic question, but I've been searching a lot an could not find an answer.
I am trying to implement a TLS/SSL client. This client will run on an embedded unit with Windows OS on it (XPe or WES7). My implementation uses GnuTLS.
How do I get the list of trusted authorities to my unit so my client can verify the server's certificate? Is it supposed to be a file stored on the client side, that the client is responsible for keeping up to date? Or can my client somehow get this list from the internet each time it is needed and not maintain it locally?
The Certificating Authority (CA) master certificates are stored client side and the client is responsible for keeping them up to date. Keeping them up to date isn't as hard as it sounds, as CA certificates aren't changed that often - most are valid for 5-10 years at least.
Client side storage is necessary because any given internet site your application uses might be compromised.
To get a list, you might start by looking at the CA certificates distributed with a browser or at the cacerts file distributed with Java. Before releasing your code, you'll probably want to check that the certs you use are genuine by checking them against information provided by the CA.
Go to any Windows machine and run "certman.msc" from command-line. Export each CA certificate (Intermediate Certificates, Trusted Authorities) to file (BER, PEM), then import these certificates into your embedded software. Now you can validate email certificates, the same way Windows does (i.e. using various x.509 related RFCs and CRLs)