I've started to develop an automation process which will automate certificate renewal where the certs will be used to support HTTPS traffic (TLS) to an from an Oracle Enterprise Business Suite (EBS) environment. Oracle is dependent on it's own keystore, Oracle Wallet. Instructions for setting up TLS in an EBS environment indicates that root and intermediate certs, along with the host cert, be included in the Wallet. However, I've noticed that LE is not including the root certs in the fullchain file downloaded along with the signed host cert. I notice, in reading a few of the blog entries here, that there are comments indicating that the root cert missing from the fullchain file may be by design. For me, I need the root cert for the Oracle wallet. So I'm looking for some other way to automatically (via script) to fetch your root certificates. Not having any luck finding information in this regard. Do you know if there is an API call that allows LE root certificate downloads? Maybe they are available via a curl or wget command?
It is. Your client is supposed to have the root certificate. You can find them where Bruce said, but they're usually distributed with your OS or browser, each of those will have their trust store.
It absolutely is by design. The client of the TLS connection would have the roots it trusts already in its "store". This "store" is usually managed by the O/S. If every client blindly trusted the root given by the server it defeats a key trust feature.
Perhaps your Wallet is used when making outbound connections (as a client) and you need to identify which roots you will trust?
In any case, Bruce has pointed out where to find the roots. You should probably setup both X1 and X2.
Yes, there are truststore within EBS, however they are used by specific applications within the product. For Oracle HTTP Server the root cert needs to be installed in the Oracle Wallet used by the server. This is per the TLS for EBS implementation guide.
Regarding the Chains of Trust - Let's Encrypt link, yes, I have reviewed this page. There is a lot of information regarding LE's certificate chain structure but I am not finding instructions for automating a download of the root certs. I am not finding any links that allow downloads either.
Yes, I could get the root certs thru a manual process. However, my goal is to automate certificate renewal for Oracle's HTTP Server (OHS). Based on everyone's reply to this post, should I assume that there is no facility setup to allow the LE root certs to be downloaded via API, curl or wget?
The challenge is that building a custom trust store isn't really something one can automate. On the client side, what you're trying to do is figure out what Certificate Authority roots you trust to validate that the certificates they issue have corresponding private keys controlled by the same entity that controls the domain name listed in them. Browsers and operating systems work hard to maintain a list for "normal users" so in general they don't need to think about it. If you're planning on only trusting Let's Encrypt issued certificates, then you'd need to download their roots from that page, and subscribe to the API Announcements category here on the forum to get notified when newer roots are created and what they might be for.
But if what you're really trying to do is have your client trust a server that you also control, it might be easier to just use a private CA (or single self-signed certificate) instead of trying to bring the publicly-trusted WebPKI into things.
I'm not familiar with the Oracle tools you're mentioning, and so it's not completely clear to me why you're trying to associate the roots used by a client with an automatic renewal of a certificate for the server.
Thank you for your help in finding the links you mention. They don't really standout in my browser. Maybe I can work with this.
To Peter,
For what its worth, I've actually written scripts, currently used to support Oracle EBS production environments, that semi-automates the creation of an Oracle Wallet used in support of Oracle's HTTP Server (OHS). Today there are a total of three scripts. The first creates the Oracle Wallet keystore to include a private key. The second imports the signed host cert along with the signer's root and any intermediates needed. The third script distributes the newly created Wallet to all required locations within the system. Along the way, the one major truststore and cacerts used are also updated. Keep in mind that the major truststore and cacerts are being used to support other applications within the system and are not used to support OHS. Unfortunate isn't it.
Due to the looming shortening of the cert renewal cycle, I'm working to develop a way to full automate the process. Typically the clients I support will use a paid CA services like DigiCert and others. What we normally see from the paid services we've worked with so far is that the fullchain file provided, once the host cert is sign, usually includes the root and any intermediates used in the signing process. From an automation perspective, this makes coding a solution a bit simpler. No need to programmatically figure out what root was used in the signing effort and then try to match and extract from another source so that you could then use the extract as import to the Wallet.
Just a bit of background...
Thank you all, once again, for your help! I'll attempt to develop something useful here via other means.
It doesn't make much sense to have the root certificate installed on the server side. While I could perhaps think of some reasons (verify the entire chain up to the root instead of just relying on the user/CA that the chain is correct), it's mainly the client side that needs the root certificate for usage in their trust store.
That said, all the intermediates contain the following part:
Authority Information Access:
CA Issuers - URI:http://x2.i.lencr.org/
which you can extract using simple commands (OpenSSL should do the trick) and download.
I was actually just looking at it, but it doesn't look like there's an easy way to just get the URL by itself from OpenSSL, one will need to do some grep/awk/etc. type stuff to it as well, since its output is kind of verbose:
$ openssl x509 -in e5.pem -noout -ext authorityInfoAccess
Authority Information Access:
CA Issuers - URI:http://x2.i.lencr.org/
But maybe that's useful. Still seems like something weird about the setup if the server is looking for it, though.
Should do the trick, unless the "CA Issuers" gets renamed somehow.
Or mabye add a grep on URI also, because RFC 5280 states:
An authorityInfoAccess extension may include multiple instances of the id-ad-caIssuers accessMethod. The different instances may specify different methods for accessing the same information or may point to different information. When the id-ad-caIssuers accessMethod is used, at least one instance SHOULD specify an accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.