Tomcat virtual hosting with SSL

Blog
5/7/18
Lluís Turró Cutiller
1,778
0

This 2018 I needed to install an SSL Certificate for a web application. Since Tomcat 9 features virtual hosted web application with differentiated SSL hosts, the next step were easy to guess: move to Java 10 plus Tomcat 9 and make use of these new features. This article goes about the process to its final ending, this web site.

First issues when migrating

Java 9 and above no longer include JAXB. Simply add the JAXB library to Tomcat 9.

Tomcat 9 no longer put the final slash to the URL (does not redirect). Modify conf/context.xml to include mapper attributes:

<Context ... 
	 mapperContextRootRedirectEnabled="true" 
	 mapperDirectoryRedirectEnabled="true"/>

Requirements

  • Tomcat 9, although I've been told 8.5 also supported SSL host virtualization.
  • Java 8 or higher. This example has been tested with Java 10.

Elements used for this article

  • This web site, an open source web application.
  • A Comodo Essential Certificate.
  • A full weekend

Asking for the certificate

If you already have a certificate you may want to skip this part. Otherwise, buy a certificate and continue.

First thing the provider ask for is a Certificate Signing Request. Lets generate one:

openssl req -new -newkey rsa:2048 -nodes -out [yourdomain].csr -keyout [yourdomain].key -subj "/C=[country]/ST=[state]/L=[city]/O=[organization]/OU=[department]/CN=[domain]"

Field

Description

yourdomain

This will be the file name. For example www_domain_whatever, in my case www_turro_org.

country

Two uppercase letters of your country, see ISO 3166-1.

state

Your state or province, as is.

city

Your city.

organization

Your organization name.

department

Department managing de certificate.

domain

As for Comodo Essential, the domain will apply to www.[domain] and [domain] as longer as you use www..

Recomendation: use www.domain, in my case www.turro.org.

Once executed, this command generated two files, yourdomain.csr and yourdomain.key. The CSR file is the Certificate Signing Request, and is the first thing you will need to provide when asking your certificate. The second is the Private Key. Keep them both in a secure place.

Installing the certificate into a keystore

If everything has gone well, you now have a response from the Certification Provider and some certificates in you hard disk. Copy them where you saved previous generated files, CSR and private key. If you followed the instructions, you private key is stored in [yourdomain].key file.

Now, one of the certificates you received is your certificate. The rest are called root certificate and chain certificates.

Change to convenient format

First thing we'll do is convert your private key and your certificate to PKCS12 format. Don't bother now as to why we use this format, I want a single keystore to include the whole bunch of certificates to simplify Tomcat configuration, and it turns out that Tomcat NIO likes this format. So, have it.

openssl pkcs12 -export -in [yourcertificate] -inkey [yourdomain].key -name [yourdomain] -out [yourdomain].p12

Field

Description

yourcertificate

Your certificate is one of those the certification provider sent you. As for Comodo, my certificate was www_turro_org.crt, so it was easy to point out which one was mine.

yourdomain

This will be the file name. For example www_domain_whatever, in my case www_turro_org.

Import private key and certificates into the keystore

This step creates a new keystore file.

keytool -importkeystore -destkeypass [password] -destkeystore [yourdomain].keystore -srckeystore [yourdomain].p12 -srcstoretype PKCS12 -srcstorepass [password]

Now, add the root and chain certificates. Bellow the example with Comodo certificates. You may follow instructions provided for your own certificate provider. Notice that the only pattern used is alias equal to certificate file minus extension.

keytool -import -trustcacerts -alias AddTrustExternalCARoot -file AddTrustExternalCARoot.crt -keystore [yourdomain].keystore
keytool -import -trustcacerts -alias COMODORSAAddTrustCA -file COMODORSAAddTrustCA.crt -keystore [yourdomain].keystore
keytool -import -trustcacerts -alias COMODORSADomainValidationSecureServerCA -file COMODORSADomainValidationSecureServerCA.crt -keystore [yourdomain].keystore

If you followed the instructions, you have a keystore named [yourdomain].keystore with everything required by Tomcat.

Installing the keystore

Let's explain something about Tomcat. Tomcat has a single Connector for SSL configuration. Once you configure your keystore, it will be available by all the web application installed, but will only certificate your domain. So, where SSL hosting virtualization is?

Don't panic, there is SSL hosting virtualization. You achieve the goal by creating SSLHostConfig elements with hostName attribute set to match one of the Host elements its name attribute. One of them will need to be the defaultSSLHostConfigName attribute in the Connector element. Messy? See the server.xml example with the values we used:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" 
           SSLEnabled="true"
           scheme="https"
           secure="true"
           defaultSSLHostConfigName="[domain]"
           
           ...

           >
    <SSLHostConfig hostName="[domain]">
        <Certificate certificateKeystoreFile="[yourdomain].keystore"
                     certificateKeystorePassword="[password]"/>
    </SSLHostConfig>

    ....

</Connector>

...

<Engine name="Catalina" defaultHost="[domain]">

  <Host name="[domain]"  appBase="/anyfolder" 
        unpackWARs="false" autoDeploy="false">
  </Host>

  ...

</Engine>

Let's suppose we followed the steps with [domain2] values. The server.xml will look like:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150" 
           SSLEnabled="true"
           scheme="https"
           secure="true"
           defaultSSLHostConfigName="[domain]"
           
           ...

           >
    <SSLHostConfig hostName="[domain]">
        <Certificate certificateKeystoreFile="[yourdomain].keystore"
                     certificateKeystorePassword="[password]"/>
    </SSLHostConfig>

    <SSLHostConfig hostName="[domain2]">
        <Certificate certificateKeystoreFile="[yourdomain2].keystore"
                     certificateKeystorePassword="[password2]"/>
    </SSLHostConfig>

    ....

</Connector>

...

<Engine name="Catalina" defaultHost="[domain]">

  <Host name="[domain]"  appBase="/anyfolder" 
        unpackWARs="false" autoDeploy="false">
  </Host>

  <Host name="[domain2]"  appBase="/anyfolder2" 
        unpackWARs="false" autoDeploy="false">
  </Host>

  ...

</Engine>

Now everything is more clear. [domain] is the default SSL configuration, but when somebody visits [domain2] there is a match between SSLHostConfig its hostName attribute and Host its name attribute. Thus, [yourdomain2].keystore will be used.

Restart your Tomcat and... That's all!

Detect the charset in Java strings

Blog
12/13/17
Lluís Turró Cutiller
12,752
0

Before start, I would like to mention Apache Tika and juniversalchardet. Tika is a full-featured file type detection library and, because so much features, takes a big amount of dependencies. I haven't tried juniversalchardet for does not detect ISO-8859-1, which is the reason I needed charset detection.

Since none well suited my problem, I decided to detect charsets myself and, once results were in production, share it with anyone else. Hope you like it

Why charset detection?

Anyone developing web applications with data inputs and third-party frameworks, with a different charset than UTF-8, might have encountered the need to auto-detect charset. Guessing the source of the input on utility classes, or passing the charset along among methods, doesn't seem to be the right way and isn't always possible.

Changing the string charset

We'll need a convert method, in order to change the string charset. The most simple way would be using String supplied methods. Something like:

public String convert(String value, String fromEncoding, String toEncoding) {
  return new String(value.getBytes(fromEncoding), toEncoding);
}

The problem remains, though. The variable fromEncoding isn't always known.

Charset guessing

Guessing? Well, let's be clear, we are guessing. Also taking some premises that might be not true. For instance, we probe using UTF-8 against a set of expected charsets. The good thing about it is that we know the elements at play and can change them at will.

The approach is very simple: if I do change the string from the expected charset to UTF-8 and then back from UTF-8 to the expected charset, shouldn't be the resulting string exactly the same than the original one?

Let's put this at work:

public static String charset(String value, String charsets[]) {
  String probe = StandardCharsets.UTF_8.name();
  for(String c : charsets) {
    Charset charset = Charset.forName(c);
    if(charset != null) {
      if(value.equals(convert(convert(value, charset.name(), probe), probe, charset.name()))) {
        return c;
      }
    }
  }
  return StandardCharsets.UTF_8.name();
}

A possible call to the charset() method would be:

String detectedCharset = charset(value, new String[] { "ISO-8859-1", "UTF-8" });

As I said, the approach uses the premise that UTF-8 will behave well on all transformations and that there is a reduced set of expected charsets. I haven't tried probing the whole Charset.availableCharsets(). In case you do and find a better way, please let me know.

Missatgeria i seguretat

Blog
10/12/17
Lluís Turró Cutiller
4,875
0

Aquests dies han estat tan elèctrics a Catalunya, que moltes persones s'han mostrat preocupades per la seguretat del seu sistema de missatgeria. Anem a donar una mirada ràpida als dos més utilitzats: WhatsApp i Telegram.

Mireu la data del text. Aquestes apps solen canviar sovint i el text no valdria per res.

Els missatges

WhatsApp entrega els missatges directament al receptor, sense que existeixin a cap servidor. Els servidors s'utilitzen exclusivament per resoldre el recipient del missatge (a qui s'envia).

Telegram, en canvi, utilitza els servidors per a fer l'enviament. El missatge, doncs, existeix al servidor.

Xats (persona a persona)

WhatsApp encripta per defecte els xats normals, persona a persona. El missatge s'encripta al enviar i es desencripta al rebre.

Telegram envia el text com a text pla, sense encriptar.

Xats de grup (grups de persones)

WhatsApp encripta per defecte els xats de grup.

Telegram utilitza text pla.

Xats privats (persona a persona)

WhatsApp no té xats privats com opció. Tots ho són.

Telegram encripta els xats privats, igualant-se així a WhatsApp, però amés ofereix configurar la durada del missatge. Els missatges s'esborren un cop passat el temps configurat.

Les còpies de seguretat

Les còpies de seguretat són un dels problemes més complexes de resoldre. Es fan no encriptades i contenen tots els missatges rebuts. Els xats privats de Telegram no permeten fer còpies.

La porta del darrera

Com ja suposareu, tota conversa passa per un servidor que resol on s'envia el text. Es podria "capturar" el text, llegir-lo, i després enviar-lo com si res.

La porta del darrera és possible en els xats i xats de grup de Telegram. Impossible en el cas de xats privats de Telegram.

Pel que fa a WhatsApp, caldria que s'introduís una clau pública diferent i només serviria per a nous missatges. Els canvis de clau pública a WhatsApp són transparents, excepte que s'activi Settings -> Account -> Security -> Show Security Notifications. Un cop activada aquesta opció, si hi hagués un canvi de clau, es notificaria amb un missatge. Aturaríem llavors la conversa, fins que la clau tornés a ser la mateixa.

Estic fet un embolic i no sé què fer

Ho entenc. Aquí quatre indicacions per anar ràpid:

Xats de grup i xats normals de persona a persona

Feu servir WhatsApp. És més segur. Per evitar que en un futur es puguin veure les converses, esborreu i demaneu que esborrin el contingut del xat.

Xats de persona a persona i contingut altament sensible

Feu servir el xat privat de Telegram i esborreu un cop acabat.

Conclusió

Recordeu que les converses normals queden al dispositiu. Si li agafen el dispositiu a un dels usuaris, l'altre o els altres quedaran al descobert. Esborreu els continguts.

No sé si us heu fixat, però no hi ha possibilitat de fer un xat de grup amb contingut altament sensible. Com a la vida real.

Laments al voltant de l'independentisme

Blog
10/6/17
Lluís Turró Cutiller
5,904
0

Laments que són mentides. Laments que busquen que res canvií. Laments d'opressors i de covards.

Perquè no parlen?

Ja es va parlar, recordeu el Pacte Nacional pel Dret a Decidir. Un vuitanta percent de la població volia un referèndum. EL REFERÈNDUM, amb la pregunta clara sobre la independència de Catalunya.

Perquè es barallen?

No és real. No hi ha una baralla entre la gent que vol expressar-se votant No i la gent que votaria SÍ. La violència i la imposició venen d'aquells que no ens volen deixar expressar. Alguns de cara, com la ultra-dreta, PP i C's, d'altres amb mentides i subterfugis, com PSC i CSQEP.

La societat està dividida en parts iguals.

No és real. Sabem que hi ha un cinquanta percent que vol activament la independència. Ho sabem perquè s'han manifestat i han votat. Sabem que un vint-i-set percent vol activament quedar-se a Espanya. I tenim els votants del PSC i CSQEP que, en un moment o altre, se'ls ha enganyat dient que es volia un referèndum pactat. Sabem que els dirigents volien enganyar-los, però no sabem del cert què pensa el votant.

Però per sobre de tot això, el vint-i-set de setembre es votaven partits, no la independència.

Si extrapolem el suport a la independència via manifestacions, llavors no hi ha color. Pel dotze d'octubre, per omplir plaça Catalunya, cal que vingui gent de fora. Les manifestacions per la unitat d'Espanya són, des de sempre, un fracàs. Espanya no motiva prou.

És il·legal

És l'eufemisme del No vull saber el resultat. D'acord, és il·legal a Espanya, i què? Si ens emparem en la legalitat per sobre dels drets fonamentals i les injustícies, mai canviarem res. I el reguitzell de canvis fets és molt llarg. Esclavitud, masclisme, homofòbia...

Ja sé, alguns direu que aquests casos no són comparables a voler la independència. Teniu raó. Però són comparables a treure el dret d'expressió a la gent. Als del Sí i als del No. És el que heu fet.

Per acabar...

Sento dir-ho, però els que us lamenteu així sou uns querellots. No heu tingut valor per posicionar-vos vers una pregunta clara. Volíeu que guanyés el No per pebrots, sense una votació. Els vostres laments no em fan llàstima. Em fastiguegen.

'Hacienda' també dirà SII

Blog
5/3/17
Lluís Turró Cutiller
3,907
0

Després de tres anys pagant a la Hisenda Catalana, usant el mètode de Sobirania Fiscal ideat per Catalunya Diu Prou (Ara o Mai), aquest any el meu gestor em diu que, amb les festes de Setmana Santa, s'ha fet impossible pagar abans del dia 15, així que liquidarà a la Hacienda. Ja sé que reben els diners igualment, però que voleu que us digui, em va entrar mal de panxa.

Canvis per a no canviar

A principis d'any, Montoro anunciava que a partir de l'u de juliol hi hauria canvis en la manera com es liquida l'IVA trimestralment. No se n'ha sentit res més des de llavors, per tant tot quedarà igual. Sembla que liquidar, el que és liquidar, ens liquidaran igual.

Sí canviarà com declaren l'IVA les grans empreses (més de sis milions l'any), els grups d'IVA i els inscrits en el Registre de Devolució Mensual de l'IVA. El sistema ideat per la Hacienda es diu Suministro Inmediato de Información, escurçant SII. Aquest SII de la Hacienda permetrà que els afectats deixin de presentar alguns models, com el resum anual d'IVA (390), per exemple. Per tal de gaudir d'aquests avantatges, queden en mans dels implantadors de sistemes informàtics necessaris per poder subministrar immediatament informació.

A tot l'estat, hauran d'usar obligatòriament el SII uns seixanta-tres-mil contribuents, que representen un vuitanta percent de la facturació empresarial.

Posant-ho fàcil?

Mireu, em peto de riure quan a la pàgina de la Agència Tributària Espanyola anuncien el sistema com una renovació necessària després de trenta anys usant l'anterior sistema. Calia facilitar els tràmits. Facilitar què? I a qui? Per donar-vos una idea: si vols connectar amb la Agència Tributària cal que ho facis usant un client Web Service amb el protocol SOAP. Tranquil, vol dir Simple Object Access Protocol. Així encara semblaràs més simple si no connectes.

Som al 2017 i qualsevol empresari pot moure milers d'euros entre comptes bancaris sense cap problema. Però el mateix empresari segueix no podent comunicar amb Hacienda sense vendre's l'ànima al diable.

A tot això, ve la independència

Per l'u de juliol, Oriol Junqueras va anunciar la posta en marxa de la Hisenda Catalana. Ja sabeu, aquelles coses que quan les diuen se't posa pell de gallina i t'estimes un piló per ser tan collonut i tan català.

Ara seriosament, heu rebut cap notificació respecte el que s'ha de fer? Tindrem un gran cartell que posi Hisenda Catalana mentre declarem a Hacienda usant el SII?

Es parla molt de ser rigorós i de fer les coses bé.

Llavors, per què anem de bòlit?


© turro.org, 2011-2018

lluis@turro.org
Tel. +34 609323947