While developing web sites/applications locally, to facilitate development, you often use a local host name, such as, localhost, site.local, example.test, or While you can access the site/application using normal HTTP, sometimes the application is configured for secure HTTP i.e. HTTPS or you always want to force HTTPS no matter the environment (dev/qa/prod).
However, ‘made up’ local host names such as example.test, site.local, etc can not use an external ssl certificate, as they cannot be accessed remotely to verify authenticity by a certificate authority (CA). So typically one would create a self signed certificate. But over time, browsers have restricted the acceptance of self signed certificates, resulting in a less friendly or impossible developer workflow. So the next step would be to add your own CA to your local environment, but that can be tedious and error prone. Luckily, there is a utility which greatly simplifies the process, for linux, macos, and even windows -mkcert
“Using certificates from real certificate authorities (CAs) for development can be dangerous or impossible (for hosts like example.test, localhost or, but self-signed certificates cause trust errors. Managing your own CA is the best solution, but usually involves arcane commands, specialized knowledge and manual steps.
mkcert automatically creates and installs a local CA in the system root store, and generates locally-trusted certificates. mkcert does not automatically configure servers to use the certificates, though, that's up to you.”


To creating a usable self signed ssl certificate using Windows, Nginx, and Laragon (a portable LAMP stack):


Download the latest mkcert for your OS (Windows in this case)



Copy the file to a new dir


And rename to a generic mkcert.exe

Note, assuming you installed/extracted Laragon to C:/laragon
In a command window with Administrator Privileges (Run as Admin)

> cd C:\laragon\etc\ssl


Specify the destination of the CA cert

> mkdir C:\laragon\etc\ssl\mkcert


Set an temporary environment variable for mkcert to read

> setx CAROOT "C:\laragon\etc\ssl\mkcert"


By default, it would have be in you user directory

> C:\Users\<user>\AppData\Local\mkcert


Close the command window and re-open it so the environment variable can be read
In linux you might source ~/.bash_profile .. but windows


Test that the environment variable is indeed set

> cd C:\laragon\etc\ssl\
> echo %CAROOT%


Create and install your local CA

> ..\..\bin\mkcert\mkcert -install 


You will be shown a prompt warning you that you are doing what you want to do, add a local CA

After reading, ClickYes


Note, by default the CA key will be named rootCA-key.pem and the CA cert will be named rootCA.pem. The names are hard coded in the project source main.go, if you want to compile the project.
You can view the CA via the Certificate Manager
Start Menu -> Run -> certmgr
Laragon -> Menu -> Nginx -> Certificate Manager
Note, while Laragon does have its own CA which it can add, it does not seem to work with recent browser updates.
Click to Trusted Root Certification Authority -> Certificates

Scroll to find mkcert Computer\User@Computer>

Note, you can delete it if you want by Right Clicking on and select Delete


Now generate the SSL certificate, which will be signed by the CA you just added


> cd C:\laragon\etc\ssl
> ..\..\bin\mkcert\mkcert site.local "*.site.local"

Would create the SSL key and cert in C:\laragon\etc\ssl as

site.local+1-key.pem and site.local+1.pem 


Rename the files, or specify names when creating: 
> ..\..\bin\mkcert\mkcert -key-file company.localhost.key -cert-file company.localhost.crt company.localhost *.company.localhost
Which would match


Or more generically 
> ..\..\bin\mkcert\mkcert -key-file dev.localhost.key -cert-file dev.localhost.crt dev.localhost *.dev.localhost
Which would match



Note, most browsers do not support wildcards 2 levels deep ie don't use just localhost or test

Note, Chrome redirects use of the .dev tld to HTTPS, as Google now owns the official .dev tld. While using any domain name which you override in your /etc/hosts file should be ok, it is best to use a domain you actually own. But if that is not practical, .test, .local, .localhost are the often provided alternatives.
Edit you Nginx or Apache config to add the SSL cert and key, and reload

Using the default website in Laragon as a working example


    listen 8443;

    # Enable SSL
    ssl_certificate "C:/laragon/etc/ssl/dev.localhost.crt";
    ssl_certificate_key "C:/laragon/etc/ssl/dev.localhost.key";
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
    ssl_prefer_server_ciphers on;

Note, if you are using Skype, you may not be able to run a webserver on port 443, so choose another port, such as 8443.

Assuming you have added your local host name to /etc/hosts or



Should result in a valid SSL cert.



Enjoy your HTTPS, and develop away.

To install reinstall on a computer, or reinstall after deleting the mkcert CA
Copy the full Laragon dir, or the rootCA.pem at least

Set an temporary environment variable for mkcert to read

> setx CAROOT "C:\laragon\etc\ssl\mkcert"

Close the command window, re-open Create and install your local CA

> ..\..\bin\mkcert\mkcert -install 


Re-enjoy your HTTPS, and develop away.



-End of Document-
Thanks for reading

MFA stands for Multifactor authentication, or Multi-factor authentication.
Multifactor authentication (MFA) is a security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction.

Note, MFA is also refereed to as 2FA or Two Factor Authentication

If you want to 'force' MFA for your users in AWS, you can follow the AWS tutorial:
'Enable Your Users to Configure Their Own Credentials and MFA Settings'
which creates a custom Policy and assigns it to a Group and then a User. 

Users with this Group will be 'forced' to add MFA before they can access resources.
'Forced' is a misnomer though. Once logged in, it may appear that you can do stuff, but most pages show non friendly errors that you do not have access, and what Policy to add to enable access. So IAM admin friendly, but not user friendly. Once you have enabled and logged in using MFA, you will able to access resources. So 'told to' or 'resigned to' would be a better Policy description. It would be nice if there was an official AWS Policy to force MFA and the only screen you saw upon login was that. But oh well, the Tutorial does 'work',  so that's all good.

But, what if when you create the user, you required the user to change their password on initial login.
The Policy listed in the AWS tutorial does not allow the user to change their password if they have not enabled MFA. So a chicken egg problem.  Or an angry user if devops didn't test first, or a frustrated devops if they did test first. 

To allow a user to change their password on initial Login, edit the Policy supplied by AWS.
Simply add the iam:ChangePassword permission to the DenyAllExceptListedIfNoMFA list.

    "Effect": "Deny",
      "NotAction": [

So now a new user can login, change their password, see a bunch of pages which they can't do anything with (uhg), go to their Security Credentials and enable MFA, logout, login with MFA and then be able to get to work.

 -End of Document-
Thanks for reading

Android Studio is the official integrated development environment for Google's Android operating system, built on JetBrains' IntelliJ IDEA software and designed specifically for Android development. It is available for download on Windows, macOS and Linux based operating systems.

When you install Android Studio, there is an option to install the Intel Emulator (HAXM).
But if you do not have a Intel CPU, but instead have a AMD CPU, HAXM is not very useful.
So uncheck that.  But luckily, there is an option for AMD CPUs after installation. 

Android Studio -> Tools -> SDK Manager
SDK Tools tab

In the list, there is an option for the AMD Emulator
Android Emulator Hypervisor Driver for AMD Processors (installer)

Which "makes it possible to the emulator on AMD CPUs without needing to enable Hyper-V and with performance on par with HAXM"

You can also uncheck the 
Intel x86 Emulator Accelerator (HXAM installer)
if you checked it during the initial install.

You may also want to check the 
Google USB Driver 
if you want to later debug/test with an a phone connected via usb

Also, you will need to enable Windows Hypervisor Platform
Note: You do not have to install the full Hypervisor VM, so you can still use VirtualBox or such.

Control Panel -> Programs and Features-> Turn Windows features on or off (left side)
Scroll down, enable Windows Hypervisor Platform

Even if not prompted to reboot on save, you need to reboot to enable the feature

You should now be able to create and launch an Android Emulator
Tools -> AVD Manager
Select an x86_64 image with google play

 Click Next and Finish
Note: You may still be prompted with an Intel HAXM dialog, probably a Android Studio bug.
Obviously Intel HAXM will fail to install/configure. But that is OK as the Android Emulator will still launch.
You should now have a usable Android Emulator, code away.

-End of Document-
Thanks for reading

Flutter is a SDK for building high-performance, high-fidelity apps for iOS, Android, and web (tech preview) from a single codebase. The goal is to enable developers to deliver high-performance apps that feel natural on different platforms.
To build Android apps with Flutter, you will need to install the Android SDK. But if you install the Android SDK to a custom location, as you might to organize your tools, Flutter will not be able to find it and thus not work. The following resolves this issue:
The short version:

> cd c:\dev\git\flutter
> flutter doctor
> flutter config --android-sdk c:\dev\android\sdk
> flutter doctor --android-licenses

> flutter doctor

The long version:
Assuming you have followed the Flutter installation instructions
You should have the Flutter SDK extracted or git cloned in a directory, such as

> c:\dev\git\flutter

And updated the environment Path to include


And installed Android Studio, which will install the Android SDK.
The default install location is usually


But you may want a shorter and more accessible location such as


Which is what causes Flutter to be flustered to not find the Android SDK
After all those downloads and installs,
You should run flutter doctor, which validates your installation

> cd c:\dev\git\flutter
> flutter doctor

Well, the first error is Flutter cannot find the Android SDK.

If you installed the Android SDK into a custom location, such as


You will need to tell Flutter about its location,
which is not in the installation instructions.

But some internet searching yielded flutter has an option to update its config

> flutter config --android-sdk C:\dev\android\sdk

Running flutter doctor again yields

> flutter doctor

I guess if you run a Flutter project or run the emulator you may get the license prompts then, but might as well accept them now.

> flutter doctor --android-licenses

Make sure you thoroughly read them, and dispute them if you do not agree, yup.

Running flutter doctor again yields

> flutter doctor

So all good.
Flutter knows where the Android SDK is installed.

Note: While IntelliJ IDEA Ultimate Edition can also be used for Flutter and Android development, Android Studio is gracefully made by IntelliJ so the interfaces are similar, with Android Studio obviously being more targeted toward Android development. Also most tutorials, internet how/what searches will reference Android Studio.

-End of Document-
Thanks for reading