This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C7C75B.8461C5E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit



hold on! thanks a lot I managed to get it to 23:59:59. all i had to do was
change the value
strcpy(buf+6, "235959Z"); to strcpy(buf+6, "155959Z");

I would not do that. There is no way you can know that 15:59:59 will
correspond to 24:59:59 in the future when the certificate expires. You are
essentially predicting what the time zone shift will be at some future date.
I would strongly urge you to make it expire at midnight UTC/GMT time.

I would go further as to say that whatever tool is presenting certificate
expiration times to you as '1/8/2007 7:59:59' (which is the way you pasted
it) should be dumped and replaced with something sane. This contains no time
zone indicator or GMT offset. If you paste it to a mailing list, it is
meaningless.

If your requirement really is that a certificate expire at midnight for
the time zone in which it was issued, assuming the zone offset will be the
same at certificate issue time as it was at certificate issue time, then the
requirement should be re-examined. For one thing, '155959Z' can't possibly
be right for every possible case (unless your locality has no daylight
savings time and you get lucky and it never does).

You are assuming that 15:59:59 local time will correspond to 24:59:59 UTC
time at the time and place the certificate is being used when it expires.
This seems like a truly crazy assumption. It might be sensible if three
things are the case:
1) The locale you are using the certificate has no daylight savings time.
2) The certificate isn't going anywhere, it's only going to be used in one
place.
3) The certificate expires in the near future, so a risk of a change in
daylight savings time rules is low.

Otherwise, this is broken.

erm... but there's still one problem. where in IssueCertificate should I
add the line
X509_gmtime_roundup(X509_get_notAfter(x)); ?
because currently the line is only added in renewCertificate... as I can't
see where in IssueCertificate can I add those lines.. thanks again

You didn't paste the code to IssueCertificate. You should be able to find
where it sets the expiration time and modify it just like the others. If
not, why are you monkeying in security-critical code?

Please don't take this the wrong way -- but you are modifying
security-critical code based on a requirement that seems to make no sense.

DS

------=_NextPart_000_0019_01C7C75B.8461C5E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



charset=3Diso-8859-1">



 

style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
hold on! thanks a lot I managed to get it to 23:59:59. all i had =
to do=20
was change the value
strcpy(buf+6, "235959Z"); to  =
strcpy(buf+6,=20
"155959Z");
color=3D#0000ff=20
size=3D2> 

color=3D#0000ff size=3D2>I=20
would not do that. There is no way you can know that 15:59:59 will =
correspond=20
to 24:59:59 in the future when the certificate expires. You=20
are essentially predicting what the time zone shift will be at =
some=20
future date. I would strongly urge you to make it expire at midnight =
UTC/GMT=20
time.

color=3D#0000ff=20
size=3D2>
 

color=3D#0000ff size=3D2>I=20
would go further as to say that whatever tool is presenting =
certificate=20
expiration times to you as
size=3D2>'1/8/2007 7:59:59'=20
color=3D#0000ff=20
size=3D2>(which is the way you pasted it) should be dumped and =
replaced=20
with something sane. This contains no time zone indicator or GMT =
offset. If=20
you paste it to a mailing list, it is meaningless.

class=3D867273710-16072007> size=3D2> 

color=3D#0000ff=20
size=3D2>If your requirement really is that a certificate =
expire at=20
midnight for the time zone in which it was issued, assuming =
the zone=20
offset will be the same at certificate issue time as it was at =
certificate=20
issue time, then the requirement should be =
re-examined.
  face=3DArial color=3D#0000ff size=3D2> For one thing, '155959Z' =
can't possibly=20
be right for every possible case (unless your locality has no daylight =
savings=20
time and you get lucky and it never =
does).

class=3D867273710-16072007> size=3D2>

color=3D#0000ff size=3D2>You=20
are assuming that 15:59:59 local time will correspond to 24:59:59 UTC =
time at=20
the time and place the certificate is being used when it expires. This =
seems=20
like a truly crazy assumption. It might be sensible if three =
things are=20
the case:

color=3D#0000ff size=3D2>1)=20
The locale you are using the certificate has no daylight savings=20
time.

color=3D#0000ff size=3D2>2)=20
The certificate isn't going anywhere, it's only going to be used in =
one=20
place.

color=3D#0000ff size=3D2>3)=20
The certificate expires in the near future, so a risk of a change in =
daylight=20
savings time rules is low.

color=3D#0000ff=20
size=3D2>
 

color=3D#0000ff=20
size=3D2>Otherwise, this is broken.

 

erm... but there's still one =
problem.=20
where in IssueCertificate should I add the line
color=3D#0000ff> size=3D2>X509_gmtime_roundup(X509_get_notAfter(x)); ?
style=3D"COLOR: rgb(0,0,0)">because currently the line is only added =
in=20
renewCertificate... as I can't see where in IssueCertificate can I add =
those=20
lines.. thanks again


color=3D#0000ff> size=3D2>You didn't paste the code to IssueCertificate. You should be =
able to=20
find where it sets the expiration time and modify it just like the =
others. If=20
not, why are you monkeying in security-critical=20
code?

color=3D#0000ff> size=3D2> 

color=3D#0000ff=20
size=3D2>Please don't take this the wrong way -- but you are modifying =

security-critical code based on a requirement that seems to make =
no=20
sense.

color=3D#0000ff=20
size=3D2>
 

color=3D#0000ff> =
size=3D2>DS