WeetA

Quand normalement rime avec rarement !

Fortinet Fortigate - Deep inspection - Untrusted certificate issue

You have configured SSL deep inspection with your own PKi CA certificate.
Most of the time, it works as expected. The Fortigate automatically generates a certificate signed by your PKi CA certificate.
The client browser doesn't report any error.

Some time, the generated certificate is not signed by your PKi CA certificate but by the default Fortinet "Fortinet_CA_Untrusted" certificate. Of course, you have not deployed this CA certificate on your computers as it should not be used. So, you obtain a SSL error.

Why the Fortigate generates a certificate with the wrong CA? The destination certificate seems to be fine. No error reported on a browser of a computer without deep inspection.

Quick answer. The destination certificate is not trusted by the Fortigate because of missing intermediate certificates on the destination server.

To avoid this issue, you have to define your PKi CA certificate for untrusted certificate. It can be done only through Cli.

FORTIGATE # config firewall ssl-ssh-profile
FORTIGATE (ssl-ssh-profile) # edit "MyDeepInspectionProfile"
FORTIGATE (MyDeepInspectionProfile) # set untrusted-caname "MyPkiCA"
FORTIGATE (MyDeepInspectionProfile) # end

Replace "MyDeepInspectionProfile" by your custom deep inspection profile and "MyPkiCA" by your PKi CA Certificate name

Pi-Hole v3.3 - Whitelisting through Web UI doesn't work as expected

When you add a domain in whitelist through Web UI, the website is still blocked.

Solution 1 - Use command line:

Remove the domain from Web UI and add it by using pihole command line

pi@raspberrypi:~ $ pihole -w weeta.net
  [i] Adding weeta.net to whitelist...
  [i] weeta.net does not exist in blacklist, no need to remove!
  [i] weeta.net does not exist in wildcard blacklist, no need to remove!

  [i] Using cached Event Horizon list...
  [i] 121,709 unique domains trapped in the Event Horizon
  [i] Number of whitelisted domains: 8
  [i] Number of blacklisted domains: 7
  [i] Number of wildcard blocked domains: 2
  [✓] Parsing domains into hosts format
  [✓] Cleaning up stray matter

  [✓] Force-reloading DNS service
  [✓] DNS service is running
  [✓] Pi-hole blocking is Enabled

Solution 2 - Move to dev branch:

The problem has been resolved in development branch.

pi@raspberrypi:~ $ pihole checkout dev
  Please note that changing branches severely alters your Pi-hole subsystems
  Features that work on the master branch, may not on a development branch
  This feature is NOT supported unless a Pi-hole developer explicitly asks!
  Have you read and understood this? [y/N] y

  [i] Shortcut "dev" detected - checking out development / devel branches...

  [i] Pi-hole Core
  [✓] Switching to branch: 'development' from 'refs/heads/master'

...

  [i] The install log is located at: /etc/pihole/install.log
  Update Complete! 

Add the domain in whitelist through Web UI.

Exchange 2016 CU2 and CU3 Configure External access domain server list empty

I just made a fresh install Of Exchange 2016 CU3.
I wanted to configure External access domain from Exchange Admin Center but Server picker didn't return any server.

It seems the problem started with CU2 (https://social.technet.microsoft.com/Forums/office/en-US/d9920875-dd18-4329-9413-f2b432953df6/no-server-displayed-in-configure-external-access-domain-window?forum=Exch2016GD)

After some investigations with IE Developer tools, i found that two filters are not defined in Query String of Server picker page request (/ecp/CertMgmt/ServerPicker.aspx)

I compared binaries from RTM and CU3, i found a difference in "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\VDirMgmt\EditExternalCASDomain.aspx"  

The following lines between </Columns> and </ecp:EcpCollectionEditor><br /> are missing in CU3 version.

                                <Content>
                                    <var data-control="Parameter" data-key="ServerRole" data-value="ClientAccess" ></var>
                                    <var data-control="Parameter" data-key="MinMajorVersion" data-value="14" ></var>
                                </Content>

 I copied them from RTM file and pasted to CU3 file but it didn't help.

Then, i compared Get-ExchangeServer | fl ServerRole result on an Exchange 2013 (as it's a fresh install of 2016 CU3, i don't have 2016 RTM installed) and on my Exchange 2016 CU3 Lab.

On Exchange 2013 (probably the same on Exchange 2016 RTM and CU1), i get the following result:
ServerRole : Mailbox, ClientAccess

On Exchange 2016 CU3 (probably the same on Exchange 2016 CU2), i get this one:
ServerRole : Mailbox

As you can see, ClientAccess is no more present.

So, i implemented the following workaround to get the server list picker working properly:
Add the following lines in "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\VDirMgmt\EditExternalCASDomain.aspx" between between </Columns> and </ecp:EcpCollectionEditor><br />

                                <Content>
                                    <var data-control="Parameter" data-key="ServerRole" data-value="Mailbox" ></var>
                                    <var data-control="Parameter" data-key="MinMajorVersion" data-value="15" ></var>
                                </Content>

You have to close "Select a Server" and "configure external access domain". After that, you should have your Exchange 2016 servers in the list.

Be careful if you have an 2013/2016 environment. Do not add Exchange 2013 servers with mailbox role only. Setting virtual directories will fail.
No problem because you installed Multirole servers of course ;)

Plugin GeoLocation 0.0.8 de NativeScript qui ne fonctionne pas sur iOS 9+

Comment perdre plusieurs heures à comprendre comment fonctionne un produit ?
En utilisant un de ses plugins buggy :)
Avant d'expliquer le problème, je tiens à dire que je débute en NativeScript.
Après avoir créé une pauvre application avec un champ text, un label et un bouton, je me suis dit comme beaucoup : "Tiens ! je vais jouer avec la position GPS"
Super, c'est bien expliqué dans la partie Hardware Access > Location de la documentation.
En gros, il faut ajouter le plugin avec la commande :

tns plugin add nativescript-geolocation

Puis, dans le fichier xml de l'UI, j'ai ajouté 2 boutons :

  • 1 pour demander l'autorisation d'accès à la position
  • 1 pour récupérer la position
<Button text="Enable Location" tap="enableLocationTap"/>
<Button text="Get Current Location" tap="getLocationTap"/>

Côté JS, il faut ajouter le code associé aux boutons :

var geolocation = require("nativescript-geolocation");
function enableLocationTap(args) {
    if (!geolocation.isEnabled()) {
        geolocation.enableLocationRequest();
    }
}
exports.enableLocationTap = enableLocationTap;

function getLocationTap(args) {
    var location = geolocation.getCurrentLocation({desiredAccuracy: 3, updateDistance: 10, maximumAge: 20000, timeout: 20000}).
    then(function(loc) {
        if (loc) {
            console.log("Current location is: " + loc);
        }
    }, function(e){
        console.log("Error: " + e.message);
    });
}
exports.getLocationTap = getLocationTap;

C'est parti, on pousse l'appli sur le iDevice à coup de :

tns run ios --release

Impec, l'appli se lance. Un petit Tap sur Enable Location et là ... rien, quedal, nada. Bon ! ça aurait dû me demander l'autorisation d'accéder à ma position.
Un petit Tap sur Get Current Location et là ...

CONSOLE LOG file:///app/main-page.js:40:20: Error: Location service is disabled

Je vous passe les Tap, reTap, rereTap, compile, clean, raahhh, plugin remove/add, platform remove/add, recherches google, github, ... rien.
J'ai cherché un peu du côté des accès demandés pour l'appli (comme les manifest Android). C'est rangé dans le fichier Info.plist.
Après vérification sur la page Cocoa Keys, les clés NSLocationWhenInUseUsageDescription et NSLocationAlwaysUsageDescription sont bien présentes.
Faut chercher ailleurs. Le plugin ne sera pas buggy ? non quand même, ça serait vraiment la loose !
Commençons par le fichier suivant qui parait, d'après son nom, bien être celui qui nous intéresse :

node_modules/nativescript-geolocation/nativescript-geolocation.ios.js

J'y retrouve notre fonction enableLocationRequest. Et là, j'ai compris. Il y a un test de version iOS 8 strict au lieu d'un test de version minimum.
J'ai oublié de vous le dire mais vous l'avez peut-être vu dans la page Cocoa Keys, les clés NSLocationWhenInUseUsageDescription et NSLocationAlwaysUsageDescription ne sont prises en charge qu'à partir de iOS 8. Avant, il fallait utiliser l'unique clé NSLocationUsageDescription.
J'ai modifié le code comme suit :

 function enableLocationRequest(always) {
-    if (platformModule.device.osVersion.indexOf("8") === 0) {
+    var intOsVersionMajor = parseInt(platformModule.device.osVersion.split('.')[0]);
+    if (intOsVersionMajor >= 8) {

Après recompilation et exécution, ça fonctionne comme prévu. Cool !
Du coup, j'ai créé un incident sur le GitHub de NativeScript pour que ce soit corrigé dans une future version : iOS 9+ Location Request does nothing

Crash au lancement des applications NativeScript en mode debug

Lorsque l'on utilise une des commandes suivantes de NativeScript 1.5.2 pour exécuter une appli sur un iDevice 64bits (iPhone 6 par exemple), l'application se lance et crash immédiatement.

$ tns debug ios
$ tns deploy ios
$ tns run ios

Le log d'Application Crash sur le iDevice remonte une exception EXC_BAD_ACCESS (SIGBUS)

Date/Time:           2016-01-29 09:23:33.45 +0100
Launch Time:         2016-01-29 09:23:32.42 +0100
OS Version:          iOS 9.2.1 (13D15)
Report Version:      105

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000015d0e070
Triggered by Thread:  0

Filtered syslog:
None found

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   ???                             0x15d0e070 0 + 366010480
1   CoreFoundation                  0x2759096b 0x274e7000 + 694635

Par contre, aucun soucis lorsque le projet est compilé directement depuis Xcode.

Le problème est connu et référencé dans le thread Crash when launching applications on iPhone 6 in debug mode #1362.

Il semblerait qu'en mode debug, la CLI de tns compile uniquement en armv7 contrairement à Xcode qui compile en arm64.

Ce sera corrigé dans l'ios-runtime 1.6.0.

En attendant le seul workaround pour compile via la CLI est d'ajouter le paramètre --release

$ tns debug ios --release
$ tns run iOS --release

 J'ai volontairement omis tns deploy --release car la commande retourne le message suivant:

When producing a release build, you need to specify all --key-store-* options.

Sauf que ces options ne sont pas dispos pour ios :) Ce problème est également connu et référencé (tns deploy ios --release command prints incorrect message. #1403)