Your doubts are valid, but the reason is wrong. The vertices are placed onto the local x/y plane, hence the normal is along the direction of the local z axis. Putting (0,0,1) into your rotation code and considering that rotation by 360° is identical to rotation by 0°, you correctly see the front of your plane. However, just using normals along x (1,0,0) or y (0,1,0) or so with your rotation code still give you the same vertices, since all transformations are the same. Changing the order of rotation does not make any difference then.
Actually, using a normal and a distance lets several degrees of freedom in an open state. Rendering a plane with vertices need those degree of freedom to be fixed. What I mean is that you need a definition of
a) an origin of the plane, so that there is a point with local co-ordinates (0,0,0),
b) an orientation angle around the normal (think of the rolling angle of a camera; the normal gives you just 2 of the 3 angles).
You solved a) by using the point
origin := (0,0,0) + distance * normal
You solve b) by just picking an angle, i.e. so that rolling is zero.
So with these fixes you have a position and an orientation as a direction and "no rolling". Let's express "no rolling" as
up_vector := (0,1,0)
And instead of a pure direction, let's use it as difference vector from the origin to a tip point
center_point := origin + normal * 1
Now (with the origin and the center point and the up vector), what we have here are the ingredients for the gluLookAt function! Although being described as a function to compute a view matrix, the function actually just builds a transformation matrix with a translation and rotations so that the z axis points in a specific direction.
The math behind the gluLookAt function isn't complicated and leaving OpenGL's matrix stack behind is ever a Good Thing TM, but I assume you may be happy with the sketched solution. Otherwise feel free to ask :)